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

.  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.


.  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.

.  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

.  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.


.  Security Considerations

   This requirements document introduces no security considerations.


.  IANA Considerations

   This requirements document introduces no IANA considerations.


.  Acknowledgments

Herbst                   Expires April 17, 2011                 [Page 5]

Internet-Draft       CPE Enhancements for v6ops             October 2010



.  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