homenet L. Howard Internet-Draft Time Warner Cable Intended status: Informational December 29, 2011 Expires: July 1, 2012 Evaluation of Proposed Homenet Routing Solutions draft-howard-homenet-routing-comparison-00 Abstract This document evaluates the various proposals for routing in an unmanaged home network. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 1, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Howard Expires July 1, 2012 [Page 1] Internet-Draft Homenet Routing Comparison December 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Consideration . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. RIPng . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. UP-PIO . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.4. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.5. MANEMO . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.6. RPL . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.7. new section . . . . . . . . . . . . . . . . . . . . . . . 13 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. Informative References . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Howard Expires July 1, 2012 [Page 2] Internet-Draft Homenet Routing Comparison December 2011 1. Introduction This document evaluates the suitability of each of the proposed routing solutions for the Homenet problem space. The list of requirements is provided in [draft-howard-homenet-routing-requirements] (soon to be included in [draft-ietf-homenet-arch]). This document is intended to assist the working group in developing consensus around a single solution, so that work may progress. 2. Requirements This section includes the requirements from [draft-howard-homenet-routing-requirements]. After each requirement is a short mnemonic, to be used in the table comparing each solution. 1. Reachability between all nodes in the home network. Links may be Ethernet, WiFi, MoCA, or any other; test all solutions against mutliple L2 types. [1. Reachability] 2. Border detection. Any solution will have to determine the routing boundary. It is assumed that no home networking device can handle a full routing table for the Internet, and that a home router should not be required to do so. [2. Border detection] A. Border may be upstream ISP, or may be a device that is a gateway to SmartGrid devices, e.g. a controller that speaks RPL to 802.15.4 and foo to home net. Or there may be no border, if no external connection has been established. [2a. Any border] B. Must be able to find "up" (a path to the Internet), but must not be dependent on "up" (Internet connectivity) existing for intra-home reachability. [2b. Find "up"] C. May be discovered by routing protocol, or other means. [2c. Border method] 3. Robust to routers being moved/added/removed/renumbered. Convergence time a few minutes or less. [3. Handles change] 4. No configuration required. It may be acceptable to require a single password or passphrase to be entered on each device, both for security, and to establish the administrative boundary. [4. No config] Howard Expires July 1, 2012 [Page 3] Internet-Draft Homenet Routing Comparison December 2011 5. Best-path is a non-requirement. [5. Null requirement] 6. Support for multiple upstream networks is a requirement. [6. Multiple upstreams] A. Including wireless offload, video-only, and split-tunnel VPN scenarios. [6a. Split up views] B. It may be assumed that each upstream will be connected via a separate router, not multihomed off the same router. [6b. Null requirement] C. Must support a prefix delegated from each provider. How hosts handle multiple prefixes is not a routing problem. [6c. Multiple PD] D. Load-balancing among providers is a non-requirement. [6d. Null requirement] E. If multiple upstream networks can provide a path to the same destination (such as an Internet host), the solution must allow for backup in case the router or link to one upstream fails. Failover time should be within a few minutes. [6e. Failover] F. Must support a "walled-garden" network. This might routing based on either source address (from the walled garden network) or destination address (to the walled garden network); support for both is not required. [6f. Walled garden] G. Source address selection is out of scope for the routing solution. Choosing which address to use to look up the destination address is out of scope for the routing solution. [6g. Null requirement] 7. Cannot assume hierarchical prefix delegation in the home, unless the Homenet working group finds consensus on a hierarchical addressing mechanism. [7. Non-hierarchical] 8. A host with mutliple upstream paths to the same destination (in- home or external) should be able to use another in case on fails. [8. Failover] 9. Prevent looping. [9. Prevent loops] 10. Should be a lightweight solution. [10. Lightweight] Howard Expires July 1, 2012 [Page 4] Internet-Draft Homenet Routing Comparison December 2011 11. Must handle multi-dwelling units or other potential dense wireless or wired networks. [11. Robust to MDUs] 12. Must be resilient to running on wireless networks. Must be able to handle both wired and wireless links. [12. Wireless] 13. Robustness in the face of unintentional joining of networks. [12. Unintended joins] 3. Consideration 3.1. OSPFv3 As documented in [OSPFv3-autoconfig]. 1. Reachability. YES, OSPF can detect reachability. 2. Border detection. NO. Any node which the router uses as a next hop, but which is not in its OSPF Area 0, may be assumed to be an external border. However, the router will have to be manually configured, or use another routing protocol, to establish a path to that next hop; therefore auto-configured OSPFv3 by itself does not detect borders. A. Any border. NO. B. Find "up". NO. Manual configuration of the router neighboring the ISP is required to set a default route. C. Border method. MANUAL. 3. Handles change. YES. OSPFv3 normally handles router additions and removals well, with link-state changes. It may not be able to handle being moved from one existing segment to another. 4. No config. YES, but requires manual configuration for security. 5. (null) 6. Multiple upstreams. YES, OSPFv3 can support multiple default routes, and multiple specific routes. A. Split up views. SOMEWHAT. OSPFv3 can certainly carry many paths, including specific routes for a wireles home agent, video cluster, or VPN concentrator. It cannot, by itself, establish routing policies determining which hosts may use those paths, so the upstream ISP may not have a return path Howard Expires July 1, 2012 [Page 5] Internet-Draft Homenet Routing Comparison December 2011 (or may have an asymmetric path). B. (null) C. Multiple PD. YES, OSPFv3 can route for multiple prefixes on a link. D. (null) E. Failover. YES, autoconfigured OSPFv3 detects link state change and reconverges in a reasonable amount of time. F. Walled garden. SOMEWHAT. OSPFv3 can carry destination routes, but cannot by itself support source-based routing. G. (null) 7. Non-hierarchical addressing. YES. 8. Failover. YES. 9. Prevent loops. YES. 10. Lightweight. NO. One estimate of a common implementation is 50,000 lines of code. 11. Robust to MDUs. YES. Full LSAs are sent periodically, but they are not onerus. 12. Wireless. YES. 13. Unintended joins. NO. Autoconfig OSPFv3 is not resilient against unintended joins unless the recommendation to use authentication hashes [OSPFV3-AUTH-TRAILER] is followed, which requires manual configuration. 3.2. RIPng Specified in [RFC2080], but no document specifying how it would be used in a Homenet environment has been written. 1. Reachability. YES, RIPng can detect reachability. 2. Border detection. NO. Any node which the router uses as a next hop, but which is not speaking RIPng, may be assumed to be an external border. However, the router will have to be manually configured, or use another routing protocol, to establish a path to that next hop; therefore auto-configured RIPng by itself does Howard Expires July 1, 2012 [Page 6] Internet-Draft Homenet Routing Comparison December 2011 not detect borders. A. Any border. NO. Some ISPs use RIP (though rarely RIPng) to communicate with customers. B. Find "up". NO. Manual configuration of the router neighboring the ISP is required to set a default route. C. Border method. MANUAL. 3. Handles change. YES. RIPng normally handles router additions and removals. It may not be able to handle being moved from one existing segment to another. 4. No config. YES. 5. (null) 6. Multiple upstreams. NO, RIPng does not forward to multiple paths for the same prefix. A. Split up views. YES, RIPng can carry multiple paths, including specific routes for a wireles home agent, video cluster, or VPN concentrator. It cannot, by itself, establish routing policies determining which hosts may use those paths, so the upstream ISP may not have a return path (or may have an asymmetric path). B. (null) C. Multiple PD. Yes, RIPng can support multiple prefixes on a link. D. (null) E. Failover. Yes, RIPng can calculate a new path when one is lost or withdrawn. F. Walled garden. SOMEWHAT. RIPng can carry destination routes, but cannot by itself support source-based routing. G. (null) 7. Non-hierarchical addressing. YES. 8. Failover. YES. Howard Expires July 1, 2012 [Page 7] Internet-Draft Homenet Routing Comparison December 2011 9. Prevent loops. SOMEWHAT. RIPng uses the original RIP count-to- infinity algorithm to prevent infinite loops; it works, but is inefficient, especially in larger networks. 10. Lightweight. YES. 11. Robust to MDUs. YES. 12. Wireless. YES. 13. Unintended joins. NO. There is no authorization method; [RFC2080] says to use the Authentication Header built into IPv6, which would allow any RIPng host. 3.3. UP-PIO As documented in [UP-PIO], this proposal would overload Router Advertisements to apporximate a distance-vector routing protocol. 1. Reachability. YES, UP-PIO will find a path, but it may not be the shortest path. 2. Border detection. YES. UP-PIO infers from DHCP-PD where the ISP network is. A. Any border. YES. A dedicated gateway, intended to run between an 802.15.4 network and a Wi-Fi or Ethernet (etc.) segment on a Homenet network, could be preconfigured to establish itself as UP for that prefix. B. Find "up". YES. C. Border method. Assume that DHCP-PD indicates upstream ISP, increment distance with RAs. 3. Handles change. YES, UP handles moves/adds/changes/deletions exactly as well as Router Advertisements do. 4. No config. YES. 5. (null) 6. Multiple upstreams. YES, whatever information is included in RAs is propagated. A. Split up views. YES. Howard Expires July 1, 2012 [Page 8] Internet-Draft Homenet Routing Comparison December 2011 B. (null) C. Multiple PD. YES. D. (null) E. Failover. F. Walled garden. YES. G. (null) 7. Non-hierarchical addressing. NO. UP depends on hierarchical addressing. 8. Failover. YES, when RAs are no longer detected, an alternate path is computed. 9. Prevent loops. Undefined; the protocol is still being defined. It is expected to prevent loops as well as RIPng. 10. Lightweight. YES. 11. Robust to MDUs. YES. 12. Wireless. YES. 13. Unintended joins. NO. Even SEND would only authenticate, not authorize. 3.4. IS-IS As defined in [RFC1195], but no document specifying how it would be used in a Homenet environment has been written. 1. Reachability. YES. 2. Border detection. NO. Any node which the router uses as a next hop, but which is not speaking IS-IS, may be assumed to be an external border. However, the router will have to be manually configured, or use another routing protocol, to establish a path to that next hop; therefore auto-configured IS-IS by itself does not detect borders. A. Any border. NO. B. Find "up". NO. Manual configuration of the router neighboring the ISP is required to set a default route. Howard Expires July 1, 2012 [Page 9] Internet-Draft Homenet Routing Comparison December 2011 C. Border method. MANUAL. 3. Handles change. YES. 4. No config. NO, IS-IS must be configured. 5. (null) 6. Multiple upstreams. YES. A. Split up views. YES. B. (null) C. Multiple PD. YES. D. (null) E. Failover. YES. F. Walled garden. YES. G. (null) 7. Non-hierarchical addressing. YES. 8. Failover. YES. 9. Prevent loops. YES. 10. Lightweight. NO. 11. Robust to MDUs. YES. 12. Wireless. YES. 13. Unintended joins. SOMEWHAT, if [RFC5310] is implemented, but that requires further manual configuration. 3.5. MANEMO No document exists describing this mechanism, though several people have suggested it to the working group. Evaluation will have to be undertaken by someone familiar with the mechanism. 1. Reachability Howard Expires July 1, 2012 [Page 10] Internet-Draft Homenet Routing Comparison December 2011 2. Border detection A. Any border. B. Find "up". C. Border method. 3. Handles change. 4. No config 5. (null) 6. Multiple upstreams. A. Split up views. B. (null) C. Multiple PD. D. (null) E. Failover. F. Walled garden. G. (null) 7. Non-hierarchical addressing. 8. Failover. 9. Prevent loops. 10. Lightweight. 11. Robust to MDUs. 12. Wireless. 13. Unintended joins. Howard Expires July 1, 2012 [Page 11] Internet-Draft Homenet Routing Comparison December 2011 3.6. RPL As documented in [RPL], but no document specifying how it would be used in a Homenet environment has been written. 1. Reachability. YES. 2. Border detection. NO. A. Any border. NO. B. Find "up". NO. C. Border method. NO. 3. Handles change. YES. 4. No config. YES? 5. (null) 6. Multiple upstreams. A. Split up views. B. (null) C. Multiple PD. D. (null) E. Failover. F. Walled garden. G. (null) 7. Non-hierarchical addressing. 8. Failover. 9. Prevent loops. 10. Lightweight. YES. 11. Robust to MDUs. Howard Expires July 1, 2012 [Page 12] Internet-Draft Homenet Routing Comparison December 2011 12. Wireless. 13. Unintended joins. 3.7. new section +-------------+--------+--------+--------+--------+--------+-----+ | Requirement | OSPFv3 | RIPng | UP PIO | IS-IS | MANEMO | RPL | +-------------+--------+--------+--------+--------+--------+-----+ | 1. | YES | YES | YES | YES | | | | 2. | NO | NO | YES | NO | | | | 2A. | NO | NO | YES | NO | | | | 2B. | NO | NO | YES | NO | | | | 2C. | MANUAL | MANUAL | PD | MANUAL | | | | 3. | YES | YES | YES | YES | | | | 4. | YES | YES | YES | NO | | | | 5. | NA | NA | NA | NA | | | | 6. | YES | NO | YES | YES | | | | 6A. | SOME | YES | YES | YES | | | | 6B. | NA | NA | NA | NA | | | | 6C. | YES | YES | YES | YES | | | | 6D. | NA | NA | NA | NA | | | | 6E. | YES | YES | YES | YES | | | | 6F. | SOME | SOME | YES | YES | | | | 6G. | NA | NA | NA | NA | | | | 7. | YES | YES | NO | YES | | | | 8. | YES | YES | YES | YES | | | | 9. | YES | SOME | TBD | YES | | | | 10. | NO | YES | YES | NO | | | | 11. | YES | YES | YES | YES | | | | 12. | YES | YES | YES | YES | | | | 13. | NO | NO | NO | SOME | | | +-------------+--------+--------+--------+--------+--------+-----+ 4. Security Considerations As an evaluation document, no security considerations are created. The solution should be safe from route injection to perpetrate man- in-the-middle attacks, especially in multi-dwelling or other dense/ mesh networks, but this may be a link requirement more than a routing requirement. 5. IANA Considerations There are no IANA considerations or implications that arise from this document. Howard Expires July 1, 2012 [Page 13] Internet-Draft Homenet Routing Comparison December 2011 6. Informative References [OSPFV3-AUTH-TRAILER] "". [OSPFv3-autoconfig] "draft-acee-ospf-ospfv3-autoconfig". [RFC1195] "Use of OSI IS-IS for Routing in TCP/IP and Dual Environments". [RFC2080] R. Minnear, "RIPng for IPv6". [RFC5310] "IS-IS Generic Cryptographic Authentication". [RPL] "draft-ietf-roll-rpl-19". [UP-PIO] "draft-howard-up-pio-00". [draft-howard-homenet-routing-requirements] "Homenet Routing Requirements", December 2011. [draft-ietf-homenet-arch] "Home Networking Architecture for IPv6". Author's Address Lee Howard Time Warner Cable 13820 Sunrise Valley Drive Herndon, VA 20171 US Phone: +1 703 345 3513 Email: lee.howard@twcable.com Howard Expires July 1, 2012 [Page 14]