Network Working Group V. Kuarsingh, Ed. Internet-Draft Rogers Communications Intended status: Informational J. Brzozowski Expires: January 5, 2014 Comcast Cable Communications C. Grundemann CableLabs J. McQueen Broadcom Corporation July 4, 2013 An incremental solution to advanced home networking draft-jvkjjmb-home-networking-incremental-00 Abstract The home network is an environment subject to ongoing evolution and change. Many home networks today are simplistic in nature, often comprising of a single router/gateway. The expectation over time is predicated on the notion that the home network will be more complex servicing many in-home and Internet functions. The home network will evolve necessitating the replacement and update to current hardware and software to more advanced devices and software capable of operating in more complex environments. This document provides a view on how the home network can progress from today's foundational form, to a more advanced environment, using progressive technological capabilities. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 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." Kuarsingh, et al. Expires January 5, 2014 [Page 1] Internet-Draft draft-jvkjjmb-home-networking-incremental July 2013 This Internet-Draft will expire on January 5, 2014. Copyright Notice Copyright (c) 2013 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. Kuarsingh, et al. Expires January 5, 2014 [Page 2] Internet-Draft draft-jvkjjmb-home-networking-incremental July 2013 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Home Network Progression and Dynamics . . . . . . . . . . . . 6 3.1. Early Home Networks . . . . . . . . . . . . . . . . . . . 6 3.2. Home Network Upgrades and Evolution . . . . . . . . . . . 7 3.3. Home Networking Progression Considerations . . . . . . . . 7 3.4. Described Phases . . . . . . . . . . . . . . . . . . . . . 9 4. Phase 1: Elementary Network . . . . . . . . . . . . . . . . . 9 4.1. Service Potential . . . . . . . . . . . . . . . . . . . . 9 4.2. Topology . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.3. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 10 4.4. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Phase 2: Medius Network . . . . . . . . . . . . . . . . . . . 11 5.1. Service Potential . . . . . . . . . . . . . . . . . . . . 11 5.2. Topology . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.3. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 13 5.4. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 14 6. Phase 3: Provectus Network . . . . . . . . . . . . . . . . . . 14 6.1. Service Service Potential . . . . . . . . . . . . . . . . 15 6.2. Topology . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.3. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 15 6.4. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 16 7. Phase 4: Posterus Network . . . . . . . . . . . . . . . . . . 18 7.1. Service Potential . . . . . . . . . . . . . . . . . . . . 18 7.2. Topology . . . . . . . . . . . . . . . . . . . . . . . . . 19 7.3. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 20 7.4. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 11.1. Normative References . . . . . . . . . . . . . . . . . . . 21 11.2. Informative References . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Kuarsingh, et al. Expires January 5, 2014 [Page 3] Internet-Draft draft-jvkjjmb-home-networking-incremental July 2013 1. Introduction The progression of the home IP network to more advanced states will require an evolution from more primitive topologies and protocol support to the eventual advanced topologies with more robust protocol support. Home networks continue to advance from environments originally intended to connect multiple subscriber hosts to a common Internet connection to future environments where Internet, teleworking, home automation, and other functions become common. In support of this evolution, this document outlines an incremental approach which begins with basic functionality laid out in [RFC6204] and culminates with more advanced topologies and functions. The more advanced home network would align well with the homenet architecture as described in [draft-ietf-homenet-arch] along with potential supporting technologies and concepts like Source Address Routing [draft-troan-homenet-sadr], multi-homing [draft-haddad-homenet-multihomed], IGP based prefix assignment [draft-arkko-homenet-prefix-assignment] and/or [draft-baker-homenet-prefix-assignment]. The criticality and evolution of the customer premises or home network is growing in complexity and importance as the variety and quantity of services being delivered using the Internet Protocol continues to increase. Coupled with these growing needs and the deployment of IPv6 an opportunity exists to advance the state of home networking in an incremental fashion. The introduction of IPv6 support within the home today to facilitate the transition allows for basic Internet access over IPv6, however, this is simply inadequate long term. Home networking technology must advance beyond providing access to Internet content, it must evolve with the goal to improve the customer experience and ensure that the in home network infrastructure is robust and reliable enough to support next generation services. As part of the evolution and the introduction of IPv6 support the home network support for IPv4 must not be overlooked. Support for IPv4 will remain in devices for years to come and IPv4 will likely continue to be used within the home as IPv4 connectivity to the Internet undergoes dramatic change during the transition to IPv6. As such it is essential that efforts to modernize home networking not only account for both IPv4 and IPv6, these activities must also allow for an incremental approach that does not require flash upgrades of the home networking infrastructure and technology or hardware replacement. Finally, as home networking technology continues to advance long term the intermediate phases must strive for interoperability to help Kuarsingh, et al. Expires January 5, 2014 [Page 4] Internet-Draft draft-jvkjjmb-home-networking-incremental July 2013 ensure a seamless transition and to act as an enabler. This is particular importance for brownfield adopters. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Terminology Home IP Network Router a node intended for home or small-office use that forwards packets not explicitly addressed to itself. Customer Edge Router (CER) a router that connects the end-user network to a service provider network. Internal Router an additional router deployed in the home or small-office network that is not attached to a service provider network. Note that this is a functional role; it is expected that there will not be a difference in hardware or software between a CER and IR, except in such cases when a CER has a dedicated non-Ethernet WAN interface (e.g. DSL/cable/ LTE modem) that would preclude it from operating as an IR. Down Interface a router's attachment to a link in the end- user network on which it distributes addresses and/or prefixes. Examples are Ethernet (simple or bridged), 802.11 wireless, or other LAN technologies. A router may have one or more network-layer down interfaces. Service Provider an entity that provides access to the Internet. In this document, a service provider specifically offers Internet access using IPv6, and may also offer IPv4 Internet access. The service provider can provide such access over a variety of different transport methods such as DSL, cable, wireless, and others. Kuarsingh, et al. Expires January 5, 2014 [Page 5] Internet-Draft draft-jvkjjmb-home-networking-incremental July 2013 Up Interface a router's attachment to a link where it receives one or more IP addresses and/or prefixes. This is also the link to which a CER or IR points its default route. depth the number of layers of routers in a network. A single router network would have a depth of 1, while a router behind a router behind a router would have a depth of 3. width The number of routers that can be directly subtended to an upstream router. A network with three directly attached routers behind the CER would have a width of 3. 3. Home Network Progression and Dynamics 3.1. Early Home Networks Early home networks, as those observed as of the writing of this document, tend to be comprised of few routing zones and layer 3 boundaries. Most home networks attached to operator networks are comprised of a single home LAN segment, or may often have a guest network based on default capabilities of off the shelf vendor platforms. The object of early home network environments was closely related to providing basic Internet connectivity for subscribers. This trend started back in the late 90's and early 2000s when traditional dial-up connections were replaced with more robust broadband connections. These newer and faster connections provided the bandwidth and flexibility to power home networks which typically used a single gateway towards the Operator's network and Internet. From an IPv6 perspective this approach was also adopted to ensure that the transition from the use of IPv4 to IPv6 could begin. The objective here has been to enable as long a period of time as possible to encourage the incremental transition to the use of IPv6 while avoiding or delaying the use impactful and costly transition technologies. Subscriber expectations during the early network phases were to connect multiple machines to the Internet over a single connection. Early Internet services were often traditional web (HTTP), Mail (SMPT/POP3/IMAP) and news (NNTP) among others. Most services other then the Internet were often supported by legacy technologies. Such Kuarsingh, et al. Expires January 5, 2014 [Page 6] Internet-Draft draft-jvkjjmb-home-networking-incremental July 2013 other services may have included legacy Video (Cable and/or Satellite TV), Voice (PSTN) and the like. 3.2. Home Network Upgrades and Evolution The home network, although originally used for very basic Internet connectivity, is now beginning to expand to support many more services. Some of the historical expansion within the home includes the use of the home network for Media like Photo viewing, Movies viewing and communications between in-home devices. During the 2000s, the home network also saw a strong growth on how it was used for more commercial functions such as online video streaming, peer to peer communications, remote teleworking, and social networking. The expansion to date did not necessarily require more complex home networks, but did expand the use of the common IP connection provided to subscribers. Some historical expansion within the home networks were related to advancement of legacy services such as voice which has transformed to VoIP in recent years. Operators often used technological frameworks, such as Packet Cable [PacketCable], to enable legacy services over IP. These newer functions expanded the home network or at times the gateway functions attaching to the operator's network. Future expansion and/or enhancements similar to VoIP in some operator networks include IPTV. The evolution of the home network continues as subscribers are beginning to use the home network to connect many new IP enabled devices. These new IP enabled devices include home security endpoints, sensors, appliances, home electronics among many others. As these new uses become prevalent in the home network, so do the needs of the attached devices, and the somewhat arbitrary ecosystem that is used to attach them. It is the expectation that this expanding ecosystem will create more robust and topologically complex home networks. It is not well understood how long or fast this evolutionary path will take, but the evolution has started. The topological attachment and addressing needs within the home network will need to be supported by the infrastructure which comprises the home network. The upstream operators will need to be cognizant of this need such as to provide the correct address sizes and/or address elements. The underlay routing platforms will also need to support the evolving home network to allow for growth and robust home network environment. 3.3. Home Networking Progression Considerations Evolving from basic to intermediate or advanced home networks there are a number of considerations. These considerations range from Kuarsingh, et al. Expires January 5, 2014 [Page 7] Internet-Draft draft-jvkjjmb-home-networking-incremental July 2013 technical matters specific to implementation to operational and deployment considerations. Unlike green field deployments most operators and customers must take into consideration that existing products and services must continue to be supported. It is also important to note that the process to upgrade must be seamless and non-disruptive. Disruption during the upgrade process will not only have direct impact to the customers of the same, but also directly impact the operators who deliver the same. Support call volumes and impacts to operator infrastructure must be factored in to the process of new technology introduction whether it is basic support for IPv6 Internet connectivity or intermediate/advanced home networking. While most modern home network devices are software upgradeable to introduce new functionality, some feature and enhancements exceed device capabilities. Further there is a large population of home networking devices that are based on an earlier generation of technology as such may not be upgradeable to even the most basic form of home networking. Fortunately operators actively work to ensure their infrastructure is modernized to ensure the greatest feature set and performance are available to their customers. For those platforms that are upgradeable, which is a non trivial population for most operators, the implementation process can be complex. Complexity is presented in many forms ranging from the technical details to integration with other essential features that must be supported. Technical functionality must be balanced with simplicity. Features that are overly complex impact implementers, customers, and operators. As such it is essential that technical solutions be implementable and supportable by vendors, deployable by operators, and usable by customers. Testing and interoperability are critical aspects of advancing any technology; this is especially the case with home networking largely due to the significant quantity of unique devices that are in use with broadband enabled home networks. The quantity and types of devices that are connected today are vast and unique, there are probably very few home networks that are alike today. As such innovators of the home network must ensure that they develop the technologies with support for legacy devices while laying the ground work for the next generation of connected devices and the services that they enable. Continued support for IPv4 to the Internet is a must at the time this document was written. While efforts advance to someday enable IPv6 only with consumer electronics and content providers support for IPv4 remains essential and cannot be ignored or forgotten. Further, at the time IPv6 only becomes a reality, it is likely that IPv4 (even for dual stack in home devices) will continue to be used, possibly Kuarsingh, et al. Expires January 5, 2014 [Page 8] Internet-Draft draft-jvkjjmb-home-networking-incremental July 2013 for decades to comes. Since it is difficult to determine if or when IPv4 will no longer be required operators and innovators must ensure that IPv4 continues to be supported. 3.4. Described Phases The phases described below are intended to provide a descriptive of how the the overall transition from early home networks can evolve to advanced home networks that support more complex functions. These phases are labeled as "Elementary" (Initial), "Medius" (Middle), "Provectus" (Advanced) and "Posterus" (Subsequent). The phase labels chosen are for reference purposes only within this document and do not hold any significance for global meaning. 4. Phase 1: Elementary Network The Elementary network phase is closely associated to the basic environment described in section two of this document. The phase is based on basic connectivity from a simple home network toward the Internet. As a starting point, future phases are built assuming this phase was generally present. While some greenfield environments may emerge, most future more advanced home networks will expand out of a basic home network. The Elementary network will likely have basic functionality at the operator/Internet edge (subscriber's point of reference) as outlined in [RFC6204]. In addition to IPv4 legacy functionality, [RFC6204] lays out basic requirements for IPv6 connectivity. With reference to IPv6, the main emphasis was the attachment of the home network to the IPv6 Internet, along with any legacy attachment to the IPv4 Internet. 4.1. Service Potential In the Elementary network, as noted, connectivity is quite basic and allows a simple home network to connect to the IPv4 and/or IPv6 Internet. Services envisioned to be used in this phase are very similar to those which are already well established. Such services include traditional Internet services such as web (HTTP), mail, news, ftp, peer to peer, social networking, teleworking among many others. Given the simplistic topological nature of this phase, there is less flexibility for downstream segments to be attached, and the in-home environment that is supported is assumed to be flat in nature (single layer 2 domain, with a potential secondary environment such as a guest net). Attaching networks, like a sensor net may not be well serviced in such a model since such environments may require layer 3 separation and/or advanced device functionality. Kuarsingh, et al. Expires January 5, 2014 [Page 9] Internet-Draft draft-jvkjjmb-home-networking-incremental July 2013 4.2. Topology The topology in the Elementary phase is basic in nature and often assumed to be flat with some exceptions for additional segments like a guest net. The topology in this phase may bridge multiple switched and WiFi environments. It is possible that tandem routers may show up in the Elementary phase, and those environments would topologically be downstream sub-network environments with little integration with the upstream IPv4 environment and likely no support for IPv6 on the sub-network/tandem LAN network (not shown in Figure 1 below). +-------+-------+ \ | Service | \ | Provider | | Service | Router | | Provider +-------+-------+ | network | / | Customer / | Internet connection / | +------+--------+ \ | IPv6 | \ | Customer Edge | \ | Router | / +---+-------+-+-+ / Network A | | Network B (Guest) | End-User ---+-------------+----+- --+--+-------------+--- | network(s) | | | | \ +----+-----+ +-----+----+ +----+-----+ +-----+----+ \ | Host | | Host | | Host | | Host | / | | | | | | | | / +----------+ +-----+----+ +----------+ +----------+ / Figure 1: Basic Home Network 4.3. Addressing Addressing in the Elementary phase will be supported by legacy IPv4 addressing behaviours and IPv6 addressing behaviours as described in [RFC6204]. IPv4 would operate much like it has for many years using [RFC1918] addressing in the home network and translating (NAT44) traffic flows to/from the Internet using a single IPv4 global address assigned to the subscriber's gateway (operating facing interface). IPv6 is expected to utilize a prefix delegation as described in [RFC6204] and allow addresses from within the delegated prefix to be assigned to hosts (or auto-configured by hosts using announced prefix) on the guest network. Kuarsingh, et al. Expires January 5, 2014 [Page 10] Internet-Draft draft-jvkjjmb-home-networking-incremental July 2013 For cases where the operator supplies a single /64, only a single segment can be supported on the home network. In cases where larger prefixes are assigned to the subscriber's gateway, additional segments can receive a /64 assignment for use on those segments. For the most part, those segments are assumed to be attached directly off the customer's edge router. Network side addressing will typically be provided by DHCPv6 [RFC3633] or RADIUS [RFC4818]. 4.4. Routing Routing in the Elementary network is also quite basic in nature. Since the layer 3 segments are typically attached to a single gateway, routing is conducted by the single gateway which uses a default route pointing to the upstream provider. The provider will have gleaned routing state which is gleaned from the DHCPv6 transaction and/or RADIUS addressing as stated in the section above. 5. Phase 2: Medius Network The Medius network extends and builds upon the concepts established in the Elementary phase. The Medius network is intended to incrementally enable and evolve the home network by going beyond basic IPv4 and/or IPv6 access to the Internet. In the Medius phase, the objective are to go beyond basic access to content and services on the Internet. Medius leverages the basic concepts established in the Elementary phase as building blocks for more advanced in home functionality while acting as a foundation for future iterations of home networking. Medius will not only act as an enabler but will also provide criticality required transition capabilities to ensure advanced phases can also be deployed seamlessly to both customers and operators with minimal disruption. 5.1. Service Potential Medius enables natively routable IP within a home or customer premise. Leveraging mostly existing techniques and technology, Medius fortifies and advances the home network to support the delivery of next generation content and services while maintaining balance from an implementation and deployment point of view. A Medius home network alleviates the notion of nest IPv4 address and port translation within a home or premises so that both IPv4 and IPv6 communications are high performance and reliable. Next generation applications, services, and content will benefit greatly from a native environment within the home as it is well known that address and port translation not only introduce latency and delays but also hamper the premise wide experience for customers. A native environment will allow customers to take full advantage of all Kuarsingh, et al. Expires January 5, 2014 [Page 11] Internet-Draft draft-jvkjjmb-home-networking-incremental July 2013 devices and applications that are and will appear throughout their home networks. 5.2. Topology The topology of a Medius home network, unlike that of the Elementary phase, will be that of a native IP network in that there is expected to be no translation within the premises. The only place where translation is likely to occur is at the premises edge facing the Internet or service provider and will be for IPv4 only, which is common place today for most home networks. Non-Medius devices will continue to be supported, however, the experience and functionality of a Medius environment may not be fully achievable. The Medius network will leverage a tree topology and can support flexibility in how sub-tended devices are connected and provisioned. However, while the Medius topology can support sub-tended devices the expectation here is that the advanced home networking phase will introduce support for greater flexibility as the need arises. The flexibility of the Medius topology meets the near to mid term flexibility requirements for the customer premises. In a Medius home network interface detection is supported allowing for devices to be connected and reconnected to one another in a manner that will enable each to be reconfigured along with any connected devices. Unlike the Elementary phase, Medius will support multiple routed segments and a home network hierarchy not just a primary segment and guest segment providing greater flexibility in how devices within the customer premises connect and access content and services over the internal segments and on the Internet. Kuarsingh, et al. Expires January 5, 2014 [Page 12] Internet-Draft draft-jvkjjmb-home-networking-incremental July 2013 +-------+-------+ \ | Service | \ | Provider | | Service | Router | | Provider +-------+-------+ | network | / | Customer / | Internet connection / | +------+--------+ \ | IPv6 | \ | Customer Edge | \ | Router | / +---+-------+-+-+ / Network A | | Network B | End-User ---+-------------+----+- --+--+-------------+--- | network(s) | | | | \ +----+-----+ +-----+----+ +----+-----+ +-----+----+ \ | Host | |Internal | | Host| |Internal | / | | | Router | | | | Router | / +----------+ +-----+----+ +----------+ +----------+ / Network C | Network D | | ---+-------------+----+- --+--+-------------+--- | | | | | \ +----+-----+ +-----+----+ +----+-----+ +-----+----+ \ | Host | | Host | | Host| | Host | / | | | | | | | | / +----------+ +-----+----+ +----------+ +----------+ / Figure 2: Progressive Home Network 5.3. Addressing The Medius network assumes greater flexibility and extensibility, and as such, the addressing within the premises must be comparable. Nodes or endpoints will be able to leverage all common techniques for both IPv4 and IPv6 addresses. For IPv4, DHCP and static addressing will be supported, however, dynamic addressing techniques are preferred. For IPv6, stateless auto-configuration with [RFC6106] support, stateless and stateful DHCPv6, and static addressing are all supported. Stateful DHCPv6 includes support for IPv6 prefix delegation [RFC3633]. For IPv6, all forms of dynamic addressing are preferred over any form of static assignments. Sub-tended routing devices in a Medius home network will leverage IPv6 prefix delegation [RFC3633]. The width and depth of the duo home network will provide the guidance required to determine the size of sub-delegated prefixes to ensure the greatest depth and width for Kuarsingh, et al. Expires January 5, 2014 [Page 13] Internet-Draft draft-jvkjjmb-home-networking-incremental July 2013 a Medius home network. While Medius home networks have flexibility for sub-delegated networks, it is expected that the typical Medius home network will have a limited quantity of connected, sub-tended devices. The overarching objective of the Medius network is to alleviate overly flat home networks while enabling high performance, reliably home networks that can be used to provide service to and support next generation content, services, and applications. In a Medius home network, IPv6 techniques can be leveraged to bootstrap the provisioning and enablement of IPv4 natively. The provisioning and enablement of IPv4 care of IPv6 enables congruent IPv4 and IPv6 topologies and routing within a customer premises. Congruent IPv4 and IPv6 help to ensure that ideal conditions are in place within the home to enable the greatest performance, reliability, and stability by dynamically altering security and routing configurations. The details of IPv6 bootstrapped IPv4 provisioning is out of scope for this document. 5.4. Routing The Medius home network does not currently require a dynamic routing protocols for routing or provisioning purposes. Provisioning techniques specified for Medius home networks are outlined in the addressing section above. Routing for duo home networks is governed by each routing device. The customer or premise edge router (facing the Internet or service provider) is aware of both IPv4 and IPv6 routing information, care of the provisioning process, for sub-tended device. Each router in a duo home network will act as a default route for all connected devices. If a routing device supports multiple connected, routed segments, routing information for all connected segments will be known inherently by the device, otherwise, the device will send all traffic to its own default route learned from its "up" interface. The Medius topology, addressing, and routing collectively act as foundational elements for future states of the home network. In fact, advanced home networking techniques may not be achievable without aspects of Mediux being deployed in customer premises networks. 6. Phase 3: Provectus Network The Provectus phase is a progressive option beyond the Medius network with the option to turn on a routing protocol. Efficiency can be gained here while keeping addressing common from the previous model. This model effectively allows for a routing protocol to be added (will be explained in routing section below in more detail) allowing Kuarsingh, et al. Expires January 5, 2014 [Page 14] Internet-Draft draft-jvkjjmb-home-networking-incremental July 2013 for better flow efficiency in-home, likely helping more advanced home networks where there are more in-home services/operations. A routing protocol can be added to an existing Medius Network as an "add on" feature. Among the advantages of having a routing protocol enabled is that it provides an efficient and dynamic network topology in the home. With respect to efficiency, a routing protocol will aid in maintaining a routing table with the sense of metric or hops to destinations. Additionally, a routing protocol can aid in the network dynamic scalability. The details of which specific routing protocol to use are out of scope for this text; however, we will discuss how some of the common routing protocols could help improve on an existing Medius Network. 6.1. Service Service Potential The main service advantage of a Provectus Network is that it will provide more seamless flexibility and transition when routers in the home are either added, removed, or moved to a different location in the network. Additionally, a routing protocol can provide a more seamless transition upon IP configuration changes. It is important to note that the added flexibility and efficiency may be lost when there are inline routers which do not support or enable the same routing protocol. In such a case, the system may revert to the Medius network operation (not as efficient, but functional). 6.2. Topology The topology for the Provectus network phase is expected to be similar to that of the Medius network phase. 6.3. Addressing The Provectus Network IP addressing considerations match those of the Medius phase with all IP addressing adhering to the HIPNet DHCPv6 and recursive prefix delegation model described above. All downstream routers to the CER will request an IPv6 prefix (IA_PD) via DHCPv6 along with an IPv6 address (IA_NA). DHCPv6 will provide address and prefix information for a specific lifetime. Upstream routers are able to create a routing table based on the address and prefix information provided to downstream routers while the DHCP lease is active. Without a routing protocol, upstream routers will not be instantly aware of when a downstream router is being removed from or moved within the home network. The upstream routers will eventually learn of a removed or moved router when the Kuarsingh, et al. Expires January 5, 2014 [Page 15] Internet-Draft draft-jvkjjmb-home-networking-incremental July 2013 DHCPv6 lifetime expires or if the router imposes other gleaning or keep alive logic to track router movement. In another scenario, an upstream HIPnet router's width or depth could be presently maximized and there is the need to replace one router connected on the width or depth with another router. The upstream router will be unable to provision the new router on the network until it detects that the previous router has been removed from the network. Without a routing protocol, the time needed to discover this topology change will most likely be longer and it places a dependency on the router which is not implementing a routing protocol to assure that it cleans up its own routing table when DHCP leases expire. 6.4. Routing A routing protocol provides either instant and/or periodic notification of the addition and deletion of downstream routers. HIPNet-based upstream routers are aware of the prefixes that are provisioned to the downstream routers and on which interface that prefix route is associated. The downstream routers will refresh and/or update that initial routing configuration. A routing protocol simplifies the efforts needed by HIPNet routers not implementing a routing protocol by eliminating the probing of routing information with DHCPv6 and perhaps, Neighbor Discovery [RFC4861] messages of downstream routers. Additionally, a routing protocol could help support a router with manual IPv6 prefix configuration. In a HIPNet router configuration, recursive prefix delegation is assumed to cascade prefix information to sub-tending downstream routers. However, with a routing protocol, it could support a directly connected router or line of routers with manual prefix configuration. The routing protocol detailed here is assumed to be carrying only route information and does not consider the presence of any other configuration data. Initially, it should also be assumed that the same routing protocol is used within the home network and there would not be the need for redistributing between multiple routing protocols. Additionally, it is assumed that there will be no configuration information passed along within the routing protocol for the Provectus phase. That is, the routing protocol will simply be used to maintain and update routing tables. Kuarsingh, et al. Expires January 5, 2014 [Page 16] Internet-Draft draft-jvkjjmb-home-networking-incremental July 2013 Some standard routing protocols to be considered for a Provectus network (but not limited to) are: - RIPng [RFC2080] - OSPFv2 [RFC2328] and/or OSPFv3 [RFC5340] / [RFC5838] - IS-IS (may also be candidate for phase 4 with multihoming) [ISO- ISIS] RIPng - Distance vector protocol (hop count based) - UDP protocol, port 521 - Multicast based messaging0 - Authentication done by IPv6 IPSEC layer Advantages of RIPng - Simple in design/implementation - Supported a network topology change immediate route update Disadvantages of RIPng - Naturally converges slowly with default 30 second reporting interval - Multicast advertisement of complete routing table on every reporting interval - Hop Limit max of 15, 16 means infinity and considered unreachable - Requires split horizon to report only those routes not sourced by the destination router. OSPF - Link state protocol (route cost based) - IP based protocol - Authentication done by IPv6 IPSEC layer Kuarsingh, et al. Expires January 5, 2014 [Page 17] Internet-Draft draft-jvkjjmb-home-networking-incremental July 2013 Advantages of OSPF - Only updates when change in route table occurs - low network overhead - Limited only by size of routing table - Low convergence time Disadvantages of OSPF - More complex in design/implementation - May be difficult to configure 7. Phase 4: Posterus Network The Posterus phase of home network development looks beyond many of the current home networking paradigms and allows more dramatic changes to surface. This phase can be characterized by two general enhancements over previous phases; IGP enhancements allowing things like prefix distribution and better multihoming capabilities, possibly through source address route selection as described in documents like [draft-troan-homenet-sadr] . The Posterus phase is the focus of much of the current work of the Homenet working group. Because the Posterus phase is the furthest into the future, it has the most potential to change over time. As such, this document captures current ideas and thinking but should not be seen as limiting in any way the potential for future progress within home networks. Additionally, many of the more dramatic changes currently envisioned for this phase (e.g. IGP prefix distribution) are not backwards compatible with existing home routers, nor those that are likely to emerge in the Medius and Provectus phases. This fundamental principle may restrain the Posterus phase deployments to those home networks which actively require the added functionality and efficiency. 7.1. Service Potential The primary and most obvious service enhancement of the Posterus phase is the enhancement of multihoming, connecting the home network to multiple ISPs simultaneously for added bandwidth and/or enhanced resiliency to WAN connectivity outages. Of course, multihoming isn't limited only to multiple ISP connections, it could also enable the connection of multiple discreet home networks thus enabling new services related to local content sharing and caching. Also, as this Kuarsingh, et al. Expires January 5, 2014 [Page 18] Internet-Draft draft-jvkjjmb-home-networking-incremental July 2013 phase leverages routing protocols specifically tailored to home networking, further service enhancements may be possible. Service discovery is one area which may benefit from such enhancements if these routing protocols are extended to share such information. 7.2. Topology Posterus supports longer term, advanced home network topologies. As mentioned above, this is primarily focused on enabling multiple ISP connections, which is illustrated in figure 3, below. Other topological changes in this phase may include connections to other, non-ISP networks and other more complex home network topologies. +-------+-------+ \ | Service | \ | Provider | | Service | Router | | Provider +-------+-------+ | network +------------+ | / | ISP 2 | | Customer / +------------+ | Internet connection / | | | +------+--------+ \ | | IPv6 | \ | | Customer Edge | \ | | Router | / | +---+-------+---+ / | Network A | | Network B | End-User | -------+----+- --+--+-------------+--- | network(s) | | | | \ | +-----+----+ +----+-----+ +-----+----+ \ +-----|Secondary | | Host 1| |Internal | / | CER | | | | Router | / +-----+----+ +----------+ +----------+ / Network C | Network D | | ---+-------------+----+- --+--+-------------+--- | | | | | \ +----+-----+ +-----+----+ +----+-----+ +-----+----+ \ | Host 2| | Host 3 | | Host 4| | Host 5 | / | | | | | | | | / +----------+ +-----+----+ +----------+ +----------+ / Figure 3: Complex Network with Two ISP Connections Kuarsingh, et al. Expires January 5, 2014 [Page 19] Internet-Draft draft-jvkjjmb-home-networking-incremental July 2013 7.3. Addressing Posterus has the potential to see the most dramatic shift in addressing of all the phases documented here. As described in [draft-arkko-homenet-prefix-assignment], one of the key enhancements in this phase may be the distribution of prefix information through an enhanced IGP. The use of IGP prefix distribution has the distinct advantage of breaking from the hierarchical prefix distribution mechanisms introduced in the Medius phase, enabling much more efficient use of the prefix' available to the home network. This is a significant advantage in home networks that are allocated a small prefix, such as a /60. Also, while the "Link ID" concept introduced in the Medius phase will allow for the use of multiple address families and multiple distinct prefixes within the home network, the IGP prefix distribution also promises to further facilitate the use of prefix' from more than one ISP. The inherent complication introduced by IGP prefix distribution is one of backwards compatibility. Home routers in the Elementary, Medius and Provectus phase, in addition to all current home routers, use DHCPv6 PD [RFC3633] exclusively for prefix distribution within the home. A home router designed to use DHCP [RFC3633] will be able to provide a prefix to a downstream Posterus phase router, but would be unable to accept a prefix delegated from an upstream Posterus phase router via an enhanced IGP. 7.4. Routing Routing in Posterus will likely introduce source address route selection, currently described in [draft-troan-homenet-sadr] and [draft-xu-rtgwg-twod-ip-routing]. Source address route selection uses both the source and destination addresses when determining the proper routing of packets leaving the home network. This will greatly enhance the multihoming capabilities of home networks by ensuring that communications initiated within the home network will always use the proper upstream ISP, avoiding ingress filtering present on most residential broadband access networks like [RFC2827]. In addition to enhanced multihoming capabilities, source address route selection may also be leveraged for access control within home networks. Since each layer 3 domain within a home network can be identified by the specific prefix' being used on that segment, source address based access control provides an effective means of implementing policy in routing. Kuarsingh, et al. Expires January 5, 2014 [Page 20] Internet-Draft draft-jvkjjmb-home-networking-incremental July 2013 8. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 9. Security Considerations No security considerations noted at this time. 10. Acknowledgements Special thanks for the following people for their contributions. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 11.2. Informative References [I-D.arkko-homenet-prefix-assignment] Arkko, J., Lindem, A., and B. Paterson, "Prefix Assignment in a Home Network", draft-arkko-homenet-prefix-assignment-04 (work in progress), May 2013. [I-D.baker-homenet-prefix-assignment] Baker, F. and R. Droms, "IPv6 Prefix Assignment in Small Networks", draft-baker-homenet-prefix-assignment-01 (work in progress), March 2012. [I-D.haddad-homenet-multihomed] Haddad, W. and D. Saucez, "Multihoming in Homenet", draft-haddad-homenet-multihomed-01 (work in progress), March 2013. [I-D.ietf-homenet-arch] Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, "Home Networking Architecture for IPv6", draft-ietf-homenet-arch-08 (work in progress), May 2013. Kuarsingh, et al. Expires January 5, 2014 [Page 21] Internet-Draft draft-jvkjjmb-home-networking-incremental July 2013 [I-D.troan-homenet-sadr] Troan, O. and L. Colitti, "IPv6 Multihoming with Source Address Dependent Routing (SADR)", draft-troan-homenet-sadr-00 (work in progress), February 2013. [I-D.xu-rtgwg-twod-ip-routing] Xu, M., Wu, J., Yang, S., and D. Wang, "Two Dimensional IP Routing Architecture", draft-xu-rtgwg-twod-ip-routing-00 (work in progress), March 2012. [ISO-ISIS] "ISO/IEC 10589:2002 Intermediate System to Intermediate System intra-domain routeing information exchange protocol", 3 2008, . [PacketCable] CableLabs, "Packet CableTM 2.0 Architecture Framework Technical Report", May 2009, . [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, January 1997. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000. [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix Attribute", RFC 4818, April 2007. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. Kuarsingh, et al. Expires January 5, 2014 [Page 22] Internet-Draft draft-jvkjjmb-home-networking-incremental July 2013 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008. [RFC5838] Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. Aggarwal, "Support of Address Families in OSPFv3", RFC 5838, April 2010. [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 6106, November 2010. [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. Troan, "Basic Requirements for IPv6 Customer Edge Routers", RFC 6204, April 2011. Authors' Addresses Victor Kuarsingh (editor) Rogers Communications 8200 Dixie Road Brampton, ON L6T 0C1 Canada Email: victor@jvknet.com John Jason Brzozowski Comcast Cable Communications 1306 Goshen Parkway Chester, PA 19380 USA Email: john_brzozowski@cable.comcast.com Chris Grundemann CableLabs 858 Coal Creek Circle Louisville, CO 80027 USA Email: c.grundemann@cablelabs.com Kuarsingh, et al. Expires January 5, 2014 [Page 23] Internet-Draft draft-jvkjjmb-home-networking-incremental July 2013 John McQueen Broadcom Corporation 16340 West Bernardo Drive San Diego, CA 92127 USA Email: jmcqueen@broadcom.com Kuarsingh, et al. Expires January 5, 2014 [Page 24]