Internet DRAFT - draft-haddad-homenet-gateway-visibility

draft-haddad-homenet-gateway-visibility






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]