v6ops D. Sturek Internet-Draft Pacific Gas & Electric T. Herbst Silver Spring Networks Intended status: Informational October 15, 2010 CPE Considerations in IPv6 Deployments draft-herbst-v6ops-cpeenhancements-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 17, 2011. Copyright Notice Copyright (c) 2010 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 BSD License. This Internet-Draft will expire on April 17, 2011. Herbst Expires April 17, 2011 [Page 1] Internet-Draft CPE Enhancements for v6ops October 2010 Copyright Notice Copyright (c) 2010 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract Smart metering deployments in residential settings introduce the prospects of ad-hoc deployment of internetworked IPv6 customer premise equipment (CPE). WiFi access points, cable boxes and other home devices with internet access could all be internetworked with smart metering devices by customers with no data networking expertise resulting in a complex multi-segment network with differing prefixes, routing support and service discovery needs. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Description . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1. Unique Local Addresses (ULAs) for Site Local Multicast. . . 3 2.2. ULA Delegation When Combining Network Segments. . . . . . . 4 2.3. Intra-network routing with multiple internet connected CPEs 4 3. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 9.2. Informative References . . . . . . . . . . . . . . . . . . 5 Authors' Address . . . . . . . . . . . . . . . . . . . . . . . . 5 Herbst Expires April 17, 2011 [Page 2] Internet-Draft CPE Enhancements for v6ops October 2010 1. Introduction The availability of energy usage information within the Home Area Network, enabled through smart meter deployment, adds a popular interconnection target for electricity customers, service providers and third party suppliers. These opportunities for energy usage management are all assuming a home owner with no data networking expertise can link together a collection of standalone networks and enable a consistent set of services and device addressing modes. This draft starts a discussion on needed standards work to make the deployment of these services a reality in an IPv6 environment. 2. Description In a regulated utility environment, utilities must deploy energy savings programs accessible to all customers. Broadband internet access cannot be assumed since around 40% of customers don't have broadband. The smart meter is then architected as a standalone border gateway with a unique prefix supplied by the smart meter. To fully enable deployment of energy savings applications onto a variety of devices, ad hoc internetworking of smart meters with HAN devices and existing networks employing diverse data links such as IEEE 802.15.4, IEEE P1901,and WiFi must be supported. The set of issues to be addressed include: o Assignment of /64 prefixes from Globally Unique Address (GUA) and Unique Local Address (ULA) [RFC4193] prefixes available to the residential network o Introduction of ULAs for a residence o ULA Delegation and Reassignment when network segments with differing ULAs are combined o Enablement of intra-network routing when CPEs within the residence are interconnected o Extensions to multicast DNS to extend local name resolution across a multi-link residential network Herbst Expires April 17, 2011 [Page 3] Internet-Draft CPE Enhancements for v6ops October 2010 2.1 Assignment of /64 prefixes from GUA and ULA prefixes The residential network that includes multiple links will need a mechanism for assigning /64 prefixes for each link from one or more shorter prefixes assigned to the network. For example, DOCSIS 3.0 uses DHCPv6-PD [RFC3633] to delegate a prefix to the residential gateway. /64 prefixes from this delegated prefix must be assigned to every link within the residential network. Similarly, the residential network may have a ULA prefix for local traffic if the residential network does not have any GUA prefixes (see section 2.2). /64 prefixes from the ULA must be assigned to the links in the residential network. 2.2 Unique Local Addresses (ULAs) IPv6 offers three types of addressing prefixes: GUA, ULA and link-local. ULA prefixes are useful in the residential network scenario for local communication when no GUA prefixes are availalbe; e.g., when the external link to the ISP is unavailable and no delegated prefixes are available. The first requirement is that gateways in the residential network create a ULA for use within the network rooted at the gateway and no other ULA prefix is available. The second requirement is that when multiple networks are created, then interconnected in a home, multiple ULAs may be present. When these networked are interconnected (by a homeowner without networking skills), the ULAs for these network segements should be harmonized without user interaction into a single set of ULAs and notification made to hosts holding references to the previous ULAs. 2.3 Intra-network routing with multiple internet connected CPEs As network segments are interconnected, and CPE devices become border gateways for new bordering network segments, a routing protocol like RIPng needs to be supported. As noted for ULA delegation, the CPE needs to automatically detect the need in support for inter-segment routing and provide support automatically. 2.4 Extensions to multicast DNS for sitewide name resolution For service discovery, two alternatives exist: user agent based Herbst Expires April 17, 2011 [Page 4] Internet-Draft CPE Enhancements for v6ops October 2010 discovery and directory agent based discovery described as follows: o User agent: Devices hold service discovery information themselves and respond to discovery requests based on matching criteria in the request. DNS Service Discovery [DNS-SD] resolved over Multicast DNS [mDNS] is an example of this type of solution. o Directory agent: Devices register service discovery information with a central repository. A well known example of this type of solution includes uPnP [uPnP] which uses the Simple Service Discovery Protocol (SSDP) [SSDP]. Note that uPnP supports both user agent and directory agent service discovery methods. mDNS only provides link-local name resolution. Use of mDNS in the residential network requires extensions so that mDNS can use site-local multicast that spans multiple hops using IP forwarding for sitewide local name resolution. 3. Future Work The following work items are proposed: o Create extensions to DHCPv6-PD to delegate prefixes across multiple links o Define precoedures for gateways to generate a ULA if required o Create procedures for HAN devices to join the ULA and procedures to combine network segments with different ULAs into a single ULA. o Define mechanisms for automated provisioning and operation of routing across multiple links in a residential networl o Create extensions to multicast DNS to support sitewide local name resolution across multiple links 4. Conclusions To realize deployment requirements of self installed, ad hoc networking where different segments can be installed and provisioned at different times and where various link technologies may be used, additional features are needed in CPE. 5. Security Considerations This requirements document introduces no security considerations. 6. IANA Considerations This requirements document introduces no IANA considerations. 7. Acknowledgments Herbst Expires April 17, 2011 [Page 5] Internet-Draft CPE Enhancements for v6ops October 2010 8. References 8.1. Normative References 8.2. Informative References [mDNS] Cheshire, S. and Krochmal, M., "Multicast DNS", draft-cheshire-dnsext-multicastdns-11 (work in progress), March 2010. [DNS-SD] Cheshire, S. and Krochmal, M., "DNS-Based Service Discovery", draft-cheshire-dnsext-dns-sd-06.txt (work in progress), March 2010. [RFC4193] Hinden, R., Haberman, B., "Unique Local IPv6 Addresses", RFC 4193, October 2005 [RFC3633] Troan, O. and Droms, R., "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. [uPnP] uPnP Forum, "uPnP Device Architecture v1.1", 15 October, 2008 [SSDP] Goland, Y., Cai, T., Gu, Y., Albright, S., "Simple Service Discovery Protocol/1.0 Operating without an Arbiter", October 1999 (expired April 2000) Authors' Addresses Tom Herbst Silver Spring Networks Redwood City, CA USA Phone: +1 650-542-4782 Email: therbst@silverspringnet.com Don Sturek Pacific Gas & Electric 77 Beale Street San Francisco, CA USA Phone: +1-619-504-3615 Email: d.sturek@att.net