Home Networking W. Haddad Internet-Draft J. Halpern Intended status: Standards Track Ericsson Expires: April 26, 2012 October 24, 2011 Ensuring Home Network Visibility to Home Gateway draft-haddad-homenet-gateway-visibility-00 Abstract This memo describes a mechanism designed to increase the home gateway visibility on the home network that it is serving. This includes knowledge of all IPv6 addresses configured using prefixes assigned by the home gateway and advertised by router(s) attached to it. 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." This Internet-Draft will expire on April 26, 2012. Copyright Notice Copyright (c) 2011 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. Haddad & Halpern Expires April 26, 2012 [Page 1] Internet-Draft Home Gateway Visibility October 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 4 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. New Messages Structures and Options Format . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Normative References . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Haddad & Halpern Expires April 26, 2012 [Page 2] Internet-Draft Home Gateway Visibility October 2011 1. Introduction With the expected proliferation of "smart home" networks, enabling multiple features and capabilities may require installing additional routers within the home that will connect to one or multiple home gateway (HGW(s)). In such scenario, it can be useful for the HGW(s) to keep track of all IPv6 addresses configured by different types of end devices that get attached to the home network via router(s) connected to the HGW(s). This memo describes a mechanism designed to address this scenario by increasing the HGW visibility on the home network that it is serving, without incurring any change on the end devices. Haddad & Halpern Expires April 26, 2012 [Page 3] Internet-Draft Home Gateway Visibility October 2011 2. Conventions used in this document 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 [RFC2119]. Haddad & Halpern Expires April 26, 2012 [Page 4] Internet-Draft Home Gateway Visibility October 2011 3. Motivation Future smart home networks are all about deploying new services within homes and enabling average users (i.e., the vast majority of Internet users) to easily interact with them. For this purpose, enabling automatic services/features discovery as well as associated home device(s) configuration (i.e., specifically for end devices that are not directly connected to the HGW) is a useful feature to provide. In fact, such feature would help assisting average user to seamlessly manage and configure home devices. Haddad & Halpern Expires April 26, 2012 [Page 5] Internet-Draft Home Gateway Visibility October 2011 4. Proposal For simplicity and better clarity, we consider in the following a home network composed of one HGW, two additional routers (R1) and (R2) and a set of home devices that are spread around the three network entities, i.e., both (R1) and (R2) are connecting a subset of home devices while the remaining ones are directly connected to the HGW. Such topology is shown in figure 1. ------- | HGW | ------- / | \ D | \ | \ ---- ---- | R1 | | R2 | ---- ---- / \ / \ D1 D2 D3 D4 Figure 1 In this topology, one home device (D) is attached to the HGW WLAN interface in addition to (R1) and (R2). Two home devices {(D1), (D2)} are connected to (R1) and a second pair {(D3), (D4)} is connected to (R2). Finally, we assume that the HGW is able to delegate prefixes to both routers, and home devices are using stateless address autoconfiguration (described in [RFC4862]), in order to generate their IPv6 addresses. Our goal is to keep the HGW fully aware of the four IPv6 addresses configured by the set of devices {D1, D2, D3, D4} despite not being directly connected to the HGW. Our suggested proposal is described in the following steps: a. when delegating prefixes to (R1) and (R2) as described in [RFC3633], the HGW issues an explicit request to get notified about IPv6 addresses that appears on each router link, i.e., IPv6 addresses configured using the corresponding delegated prefix. Such request can be sent to the requesting routers (i.e., (R1) and/or (R2)) by inserting, for example, a new IA_PD option in the DHCP (Reply) message sent by the delegating router (i.e., HGW). Haddad & Halpern Expires April 26, 2012 [Page 6] Internet-Draft Home Gateway Visibility October 2011 b. upon receiving a request to convey IPv6 addresses that are (auto)-configured using the delegated (and advertised) prefix, (R1) proceeds to collect and store all IPv6 addresses which pass the duplicate address detection (DAD) procedure performed on its link. In our example, (R1) should convey to HGW all IPv6 addresses that are configured by (D1) and (D2) while (R2) should convey the addresses that are configured by (D3) and (D4). c. (R1) sends the collected IPv6 addresses to HGW using one (or multiple) new ICMP unicast message called "ICMP Notify (ICMP_NTY)". Such message may be sent whenever a new IPv6 address is successfuly tested on the link or may be used to carry a set of IPv6 addresses. Other parameter(s) that are specific to the end device may also be sent in the ICMP_NTY message, along with the device's IPv6 address(es) (e.g., MAC address). d. After receiving a valid ICMP_NTY message, the HGW SHOULD send an acknowledgment to the sending router. For this purpose, we introduce another ICMP message called "ICMP Notify Acknowledgment (ICMP_NTA)". It follows that ICMP_NTA message MUST be sent only by the delegating router. Note that the pair of new ICMP messages is also used to convey IPv6 addresses to the HGW when end devices configure their IPv6 addresses using DHCPv6 mechanism (described in [RFC3315]). In more complicated scenarios, (R1) can be directly connected to one or multiple routers on the downstream path in which case, the prefix delegation functionality is not limited to the HGW. In such case, the suggested IPv6 address notification procedure requires the requesting router to send the ICMP_NTY messages directly to the HGW. For this purpose, the HGW address is sent by the delegating router in the DHCP Reply message (e.g., using another IA_PD option). Haddad & Halpern Expires April 26, 2012 [Page 7] Internet-Draft Home Gateway Visibility October 2011 5. New Messages Structures and Options Format TBD Haddad & Halpern Expires April 26, 2012 [Page 8] Internet-Draft Home Gateway Visibility October 2011 6. Security Considerations TBD Haddad & Halpern Expires April 26, 2012 [Page 9] Internet-Draft Home Gateway Visibility October 2011 7. IANA Considerations TBD Haddad & Halpern Expires April 26, 2012 [Page 10] Internet-Draft Home Gateway Visibility October 2011 8. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. Haddad & Halpern Expires April 26, 2012 [Page 11] Internet-Draft Home Gateway Visibility October 2011 Authors' Addresses Wassim Michel Haddad Ericsson 300 Holger Dr San Jose, CA 95134 US Phone: +1 646 256 2030 Email: Wassim.Haddad@ericsson.com Joel Halpern Ericsson PO Box 6049 Leesburg, VA 20178 US Phone: +1 703 371 3043 Email: Joel.Halpern@ericsson.com Haddad & Halpern Expires April 26, 2012 [Page 12]