idnits 2.17.1 draft-howard-homenet-routing-requirements-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 4473 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC6204' is defined on line 157, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 6204 (Obsoleted by RFC 7084) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Howard 3 Internet-Draft Time Warner Cable 4 Intended status: Informational December 29, 2011 5 Expires: July 1, 2012 7 Homenet Routing Requirements 8 draft-howard-homenet-routing-requirements-00 10 Abstract 12 This document describes the requirements for routing in an unmanaged 13 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. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 52 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 53 5. Informative References . . . . . . . . . . . . . . . . . . . . 5 54 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 1. Introduction 58 This document describes the requirements for routing in an unmanaged 59 home network. Home networks are evolving to include multiple routers 60 and potentially multiple possible exits. These exist may include 61 multiple Internet access paths (through one or more multiple access 62 providers), "walled garden" environments for video, VPN, or other 63 service access, and smart energy devices. 65 2. Requirements 67 Reachability between all nodes in the home network. Links may be 68 Ethernet, WiFi, MoCA, or any other; test all solutions against 69 mutliple L2 types. 71 Border detection. Any solution will have to determine the routing 72 boundary. It is assumed that no home networking device can handle 73 a full routing table for the Internet, and that a home router 74 should not be required to do so. 76 Border may be upstream ISP, or may be a device that is a 77 gateway to SmartGrid devices, e.g. a controller that speaks RPL 78 to 802.15.4 and foo to home net. Or there may be no border, if 79 no external connection has been established. 81 Must be able to find "up" (a path to the Internet), but must 82 not be dependent on "up" (Internet connectivity) existing for 83 intra-home reachability. 85 May be discovered by routing protocol, or other means. 87 Robust to routers being moved/added/removed/renumbered. 88 Convergence time a few minutes or less. 90 No configuration required. It may be acceptable to require a 91 single password or passphrase to be entered on each device, both 92 for security, and to establish the administrative boundary. 94 Best-path is a non-requirement. 96 Support for multiple upstream networks is a requirement. 98 Including wireless offload, video-only, and split-tunnel VPN 99 scenarios. 101 It may be assumed that each upstream will be connected via a 102 separate router, not multihomed off the same router. 104 Must support a prefix delegated from each provider. How hosts 105 handle multiple prefixes is not a routing problem. 107 Load-balancing among providers is a non-requirement. 109 If multiple upstream networks can provide a path to the same 110 destination (such as an Internet host), the solution must allow 111 for backup in case the router or link to one upstream fails. 112 Failover time should be within a few minutes. 114 Must support a "walled-garden" network. This might routing 115 based on either source address (from the walled garden network) 116 or destination address (to the walled garden network); support 117 for both is not required. 119 Source address selection is out of scope for the routing 120 solution. Choosing which address to use to look up the 121 destination address is out of scope for the routing solution. 123 Cannot assume hierarchical prefix delegation in the home, unless 124 the Homenet working group finds consensus on a hierarchical 125 addressing mechanism. 127 A host with mutliple upstream paths to the same destination (in- 128 home or external) should be able to use another in case on fails. 130 Prevent looping. 132 Should be a lightweight solution. 134 Must handle multi-dwelling units or other potential dense wireless 135 or wired networks. 137 Must be resilient to running on wireless networks. Must be able 138 to handle both wired and wireless links. 140 Robustness in the face of unintentional joining of networks. 142 3. Security Considerations 144 As a requirements document, no security considerations are created. 145 The solution should be safe from route injection to perpetrate man- 146 in-the-middle attacks, especially in multi-dwelling or other dense/ 147 mesh networks, but this may be a link requirement more than a routing 148 requirement. 150 4. IANA Considerations 152 There are no IANA considerations or implications that arise from this 153 document. 155 5. Informative References 157 [RFC6204] Cisco Systems, Inc., Cisco Systems, Inc., CableLabs, AT&T, 158 and Cisco Systems, Inc., "Basic Requirements for IPv6 159 Customer Edge Routers". 161 Author's Address 163 Lee Howard 164 Time Warner Cable 165 13820 Sunrise Valley Drive 166 Herndon, VA 20171 167 US 169 Phone: +1 703 345 3513 170 Email: lee.howard@twcable.com