idnits 2.17.1 draft-haddad-homenet-gateway-visibility-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 24, 2011) is 4568 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Home Networking W. Haddad 3 Internet-Draft J. Halpern 4 Intended status: Standards Track Ericsson 5 Expires: April 26, 2012 October 24, 2011 7 Ensuring Home Network Visibility to Home Gateway 8 draft-haddad-homenet-gateway-visibility-00 10 Abstract 12 This memo describes a mechanism designed to increase the home gateway 13 visibility on the home network that it is serving. This includes 14 knowledge of all IPv6 addresses configured using prefixes assigned by 15 the home gateway and advertised by router(s) attached to it. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on April 26, 2012. 34 Copyright Notice 36 Copyright (c) 2011 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Conventions used in this document . . . . . . . . . . . . . . 4 53 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 4. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 5. New Messages Structures and Options Format . . . . . . . . . . 8 56 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 57 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 58 8. Normative References . . . . . . . . . . . . . . . . . . . . . 11 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 61 1. Introduction 63 With the expected proliferation of "smart home" networks, enabling 64 multiple features and capabilities may require installing additional 65 routers within the home that will connect to one or multiple home 66 gateway (HGW(s)). In such scenario, it can be useful for the HGW(s) 67 to keep track of all IPv6 addresses configured by different types of 68 end devices that get attached to the home network via router(s) 69 connected to the HGW(s). 71 This memo describes a mechanism designed to address this scenario by 72 increasing the HGW visibility on the home network that it is serving, 73 without incurring any change on the end devices. 75 2. Conventions used in this document 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in [RFC2119]. 81 3. Motivation 83 Future smart home networks are all about deploying new services 84 within homes and enabling average users (i.e., the vast majority of 85 Internet users) to easily interact with them. For this purpose, 86 enabling automatic services/features discovery as well as associated 87 home device(s) configuration (i.e., specifically for end devices that 88 are not directly connected to the HGW) is a useful feature to 89 provide. In fact, such feature would help assisting average user to 90 seamlessly manage and configure home devices. 92 4. Proposal 94 For simplicity and better clarity, we consider in the following a 95 home network composed of one HGW, two additional routers (R1) and 96 (R2) and a set of home devices that are spread around the three 97 network entities, i.e., both (R1) and (R2) are connecting a subset of 98 home devices while the remaining ones are directly connected to the 99 HGW. Such topology is shown in figure 1. 101 ------- 102 | HGW | 103 ------- 104 / | \ 105 D | \ 106 | \ 107 ---- ---- 108 | R1 | | R2 | 109 ---- ---- 110 / \ / \ 111 D1 D2 D3 D4 113 Figure 1 115 In this topology, one home device (D) is attached to the HGW WLAN 116 interface in addition to (R1) and (R2). Two home devices {(D1), 117 (D2)} are connected to (R1) and a second pair {(D3), (D4)} is 118 connected to (R2). Finally, we assume that the HGW is able to 119 delegate prefixes to both routers, and home devices are using 120 stateless address autoconfiguration (described in [RFC4862]), in 121 order to generate their IPv6 addresses. 123 Our goal is to keep the HGW fully aware of the four IPv6 addresses 124 configured by the set of devices {D1, D2, D3, D4} despite not being 125 directly connected to the HGW. 127 Our suggested proposal is described in the following steps: 129 a. when delegating prefixes to (R1) and (R2) as described in 130 [RFC3633], the HGW issues an explicit request to get notified 131 about IPv6 addresses that appears on each router link, i.e., IPv6 132 addresses configured using the corresponding delegated prefix. 133 Such request can be sent to the requesting routers (i.e., (R1) 134 and/or (R2)) by inserting, for example, a new IA_PD option in the 135 DHCP (Reply) message sent by the delegating router (i.e., HGW). 137 b. upon receiving a request to convey IPv6 addresses that are 138 (auto)-configured using the delegated (and advertised) prefix, 139 (R1) proceeds to collect and store all IPv6 addresses which pass 140 the duplicate address detection (DAD) procedure performed on its 141 link. In our example, (R1) should convey to HGW all IPv6 142 addresses that are configured by (D1) and (D2) while (R2) should 143 convey the addresses that are configured by (D3) and (D4). 145 c. (R1) sends the collected IPv6 addresses to HGW using one (or 146 multiple) new ICMP unicast message called "ICMP Notify 147 (ICMP_NTY)". Such message may be sent whenever a new IPv6 148 address is successfuly tested on the link or may be used to carry 149 a set of IPv6 addresses. Other parameter(s) that are specific to 150 the end device may also be sent in the ICMP_NTY message, along 151 with the device's IPv6 address(es) (e.g., MAC address). 153 d. After receiving a valid ICMP_NTY message, the HGW SHOULD send an 154 acknowledgment to the sending router. For this purpose, we 155 introduce another ICMP message called "ICMP Notify Acknowledgment 156 (ICMP_NTA)". It follows that ICMP_NTA message MUST be sent only 157 by the delegating router. 159 Note that the pair of new ICMP messages is also used to convey IPv6 160 addresses to the HGW when end devices configure their IPv6 addresses 161 using DHCPv6 mechanism (described in [RFC3315]). 163 In more complicated scenarios, (R1) can be directly connected to one 164 or multiple routers on the downstream path in which case, the prefix 165 delegation functionality is not limited to the HGW. In such case, 166 the suggested IPv6 address notification procedure requires the 167 requesting router to send the ICMP_NTY messages directly to the HGW. 168 For this purpose, the HGW address is sent by the delegating router in 169 the DHCP Reply message (e.g., using another IA_PD option). 171 5. New Messages Structures and Options Format 173 TBD 175 6. Security Considerations 177 TBD 179 7. IANA Considerations 181 TBD 183 8. Normative References 185 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 186 Requirement Levels", BCP 14, RFC 2119, March 1997. 188 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 189 and M. Carney, "Dynamic Host Configuration Protocol for 190 IPv6 (DHCPv6)", RFC 3315, July 2003. 192 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 193 Host Configuration Protocol (DHCP) version 6", RFC 3633, 194 December 2003. 196 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 197 Address Autoconfiguration", RFC 4862, September 2007. 199 Authors' Addresses 201 Wassim Michel Haddad 202 Ericsson 203 300 Holger Dr 204 San Jose, CA 95134 205 US 207 Phone: +1 646 256 2030 208 Email: Wassim.Haddad@ericsson.com 210 Joel Halpern 211 Ericsson 212 PO Box 6049 213 Leesburg, VA 20178 214 US 216 Phone: +1 703 371 3043 217 Email: Joel.Halpern@ericsson.com