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]