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