Network Working Group J. Jeong Internet-Draft Sungkyunkwan University Intended status: Standards Track J. Park Expires: March 5, 2015 ETRI September 1, 2014 DNS Name Autoconfiguration for Home Network Devices draft-jeong-homenet-device-name-autoconf-01 Abstract This document specifies an autoconfiguration scheme for DNS names of home network devices. By this scheme, the DNS name of a home network device can be autoconfigured with the device's category and model in a home network. This DNS name lets home residents easily identify each device for monitoring and remote-controlling it in a home network. 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 March 5, 2015. Copyright Notice Copyright (c) 2014 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 Jeong & Park Expires March 5, 2015 [Page 1] Internet-Draft Homenet Device Name Autoconf September 2014 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Applicability Statements . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. DNS Name Autoconfiguration . . . . . . . . . . . . . . . . . . 4 5.1. DNS Name Format . . . . . . . . . . . . . . . . . . . . . . 5 5.2. Procedure of DNS Name Autoconfiguration . . . . . . . . . . 5 5.2.1. Procedure of Device Name Generation . . . . . . . . . . 5 5.2.2. Uniqueness Test of Device DNS Name . . . . . . . . . . 6 5.2.3. Collection of Device DNS Names . . . . . . . . . . . . 6 6. Location-Aware DNS Name Configuration . . . . . . . . . . . . . 7 6.1. Macro-Location-Aware DNS Name . . . . . . . . . . . . . . . 7 6.2. Micro-Location-Aware DNS Name . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 Jeong & Park Expires March 5, 2015 [Page 2] Internet-Draft Homenet Device Name Autoconf September 2014 1. Introduction Many appliances (such as smart TV, refrigerator, air conditioner, and washing machine) in a home network have begun to have WiFi capability for monitoring and remote-controlling within a home network or from the Internet. Also, Internet of Things (IoT) devices (such as light, meter, room temperature controller, and sensors) have been installed into home networks for the easy management of home environments. For the Internet connectivity of home network devices, a variety of parameters (e.g., IPv6 addresses, default routers, and DNS servers) can be automatically configured by Neighbor Discovery (ND) for IP Version 6, IPv6 Stateless Address Autoconfiguration, and IPv6 Router Advertisement (RA) Options for DNS Configuration [RFC4861][RFC4862][RFC6106]. For these home appliances and IoT devices, the manual configuration of DNS names will be cumbersome and time-consuming as the number of them increases rapidly in a home network. It will be good for such DNS names to be automatically configured such that they are readable to home residents. This document proposes an autoconfiguration scheme for DNS names of home network devices. Since an autoconfigured DNS name contains the device category and model of a device, home residents can easily identify the device. With this device category and model, they will be able to monitor and remote-control each device with mobile smart devices, such as smartphone and tablet. 1.1. Applicability Statements It is assumed that home network devices have Ethernet or WiFi capability (e.g., IEEE 802.11 series [IEEE-802.11] [IEEE-802.11a] [IEEE-802.11b][IEEE-802.11g] [IEEE-802.11n]) and are connected to a local area network (LAN) or a wireless LAN (WLAN). Also, it is assumed that each home network device has a factory configuration (called device configuration) having device category (e.g., smart TV, smartphone, tablet, and refrigerator) and model (i.e., a specific model name of the device). This device configuration can be read by the device for DNS name autoconfiguration. 2. Requirements Language 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 RFC 2119 [RFC2119]. Jeong & Park Expires March 5, 2015 [Page 3] Internet-Draft Homenet Device Name Autoconf September 2014 3. Terminology This document uses the terminology described in [RFC4861] and [RFC4862]. In addition, four new terms are defined below: o Device Configuration: A factory configuration that has device category (e.g., smart TV, smartphone, tablet, and refrigerator) and model (i.e., a specific model name of the device). o DNS Search List (DNSSL): The list of DNS suffix domain names used by IPv6 hosts when they perform DNS query searches for short, unqualified domain names [RFC6106]. o DNSSL Option: IPv6 RA option to deliver the DNSSL information to IPv6 hosts [RFC6106]. 4. Overview This document specifies an autoconfiguration scheme for a home network device using device configuration and DNS search list. Device configuration has device category and device model. DNS search list has DNS suffix domain names that represent DNS domains of the home network having the home network device [RFC6106]. As an IPv6 host, the home network device can obtain DNS search list through IPv6 Router Advertisement (RA) with DNS Search List (DNSSL) Option [RFC4861][RFC6106] or DHCPv6 with Domain Search List Option [RFC3315][RFC3736][RFC3646]. The home network device can construct its DNS name with the concatenation of device category, device model, and domain name. Since there exist more than one device with the same model, the DNS name should have a unique identification to differentiate multiple devices with the same model. Since both RA and DHCPv6 can be simultaneously used for the parameter configuration for IPv6 hosts, this document considers the DNS name autoconfigurtion in the coexistence of RA and DHCP. 5. DNS Name Autoconfiguration The DNS name autoconfiguration for a home network device needs the acquisition of DNS search list through either RA [RFC6106] or DHCPv6 [RFC3646]. Once the DNS search list is obtained, the home network device autonomously constructs its DNS name(s) with the DNS search list and its device information. Jeong & Park Expires March 5, 2015 [Page 4] Internet-Draft Homenet Device Name Autoconf September 2014 5.1. DNS Name Format A DNS name for a home network device has the following format as in Figure 1: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | unique_id.device_model.device_category.domain_name | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Home Network Device's DNS Name Format Fields: unique_id unique identifier to guarantee the uniqueness of the DNS name in ASCII characters. The identifier MAY be a sequence number or alphanumeric with readability, such as product name. device_model device's model name in ASCII characters. It is a product model name provided by the manufacturer. device_category device's category name in ASCII characters, such as TV, refrigerator, air conditioner, smartphone, tablet, light, and meter. domain_name DNS domain name that is encoded according to the specification of "Representation and use of domain name" of RFC 3315. 5.2. Procedure of DNS Name Autoconfiguration The procedure of DNS name autoconfiguration is performed through a DNSSL option delivered by either RA [RFC6106] or DHCPv6 [RFC3646]. 5.2.1. Procedure of Device Name Generation When as an IPv6 host a device receives a DNSSL option through either RA or DHCPv6, it checks the validity for the DNSSL option. If the option is valid, the IPv6 host performs the DNS name autoconfiguration with each DNS suffix domain name in the DNSSL option as follows: 1. The host constructs its DNS name with the DNS suffix domain name along with device configuration and a selected identifier (as unique_id) that is considered unique. Jeong & Park Expires March 5, 2015 [Page 5] Internet-Draft Homenet Device Name Autoconf September 2014 2. The host performs the uniqueness test of the constructed DNS name. The uniqueness test is performed through duplicate address detection (DAD) procedure in ND [RFC4861][RFC4862]. See Section 5.2.2 for the detailed test procedure. 3. If the DNS name is proven to be unique, it is used as the device's DNS name and the DNS autoconfiguration is done for the given DNS suffix domain name. Otherwise, go to Step 1. When the DNS search list has more than one DNS suffix domain name, the IPv6 host repeats the above procedure until all of the DNS suffixes are used for the DNS name autoconfiguration. 5.2.2. Uniqueness Test of Device DNS Name An IPv6 host generates an IPv6 address with 64-bit prefix from an RA option (or DHCPv6) and 64-bit hash value from the DNS name to be tested. Before using such an IPv6 address associated with the DNS name, the IPv6 host performs the DAD to check whether the address belongs to another IPv6 host or not. Note that the IPv6 host configures the IPv6 address corresponding to the DNS name as its address. If the address belongs to another IPv6 host, it is considered that the DNS name corresponding to the address is occupied by a different host. Thus, the IPv6 host selects another unique identifier (as unique_id) for a DNS name and repeats the uniqueness test of the new DNS name with the identifier. 1. The host computes the hash value of the DNS name to be tested for the uniqueness using a hash function (e.g., MD5 and SHA-1). It takes the first 64 bits of the hash value from most significant bit. 2. The host performs the uniqueness test of the constructed DNS name. The uniqueness test is performed through the DAD procedure in ND [RFC4861][RFC4862]. 3. If the DNS name is proven to be unique with no response for the DAD, the device configures the DNS name and the corresponding IPv6 address as its own DNS name and address, respectively, returning the success of the uniqueness test. Otherwise, return the failure of the uniqueness test. 5.2.3. Collection of Device DNS Names Once as IPv6 hosts the devices have autoconfigured their DNS names, as a collector, any IPv6 node (i.e., router or host) in the same subnet can collect the device DNS names using IPv6 Node Information (NI) protocol [RFC4620]. Jeong & Park Expires March 5, 2015 [Page 6] Internet-Draft Homenet Device Name Autoconf September 2014 For a collector to collect the device DNS names without any prior node information, a new NI query needs to be defined. That is, a new ICMPv6 Code (e.g., 3) SHOULD be defined for the collection of the IPv6 host DNS names. The Data field is not included in the ICMPv6 header since the NI query is for all the IPv6 hosts in the same subnet. The Qtype field for NI type type is set to 2 for Node Name. The query SHOULD be transmitted by the collector to a link-local multicast address for this NI query. Assume that a link-local multicast address SHOULD be defined for device DNS name collection and that all the IPv6 hosts join this link-local multicast address for the device DNS name collection service. When an IPv6 host receives this query sent by the collector in multicast, it transmits its Reply with a random interval between zero and [Query Response Interval, as defined by Multicast Listener Discovery Version 2 [RFC3810]. This randomly delayed Reply allows the collector to collect the device DNS names with less frame collision probability by spreading out the Reply time instants. After the collector collects the device DNS names, it collects the IPv6 addresses corresponding to the DNS names by NI protocol [RFC4620]. For DNS name resolution service, the collector can register the pair(s) of DNS name and IPv6 address for each IPv6 host into a recursive DNS server known to the collector using DNS dynamic update [RFC2136]. 6. Location-Aware DNS Name Configuration A DNS name can include location information to let home residents easily identify the physical location of each device. In this document, location is categorized into macro-location and micro- location according to whether the location is a physical location or device. 6.1. Macro-Location-Aware DNS Name If location information (such as living room, kitchen, and bedroom) is available to a home network device, a keyword for the location can be used to construct a DNS name as subdomain name. This location information lets home residents track the position of mobile devices (such as smartphone, tablet, and vacuum cleaning robot). The physical location of the device is defined as macro-location for DNS naming. A subdomain name for macro-location MAY be placed between device_category and domain_name of the DNS name format in Figure 1. A localization scheme for device location is beyond the scope of this Jeong & Park Expires March 5, 2015 [Page 7] Internet-Draft Homenet Device Name Autoconf September 2014 document. 6.2. Micro-Location-Aware DNS Name An IoT device (e.g., refrigerator) can have multiple other IoT devices (e.g., containers of a refrigerator) within itself. A device containing other devices is defined as micro-location for DNS naming. A subdomain name for micro-location MAY be placed between device_category and domain_name of the DNS name format in Figure 1. A localization scheme for micro-location is beyond the scope of this document. To denote both macro-location and micro-location into a DNS name, the following format is described as in Figure 2: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | unique_id.device_model.device_category.mic_loc.mac_loc.domain_name| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Location-Aware Device DNS Name Format Fields: unique_id unique identifier to guarantee the uniqueness of the DNS name in ASCII characters. The identifier MAY be a sequence number or alphanumeric with readability, such as product name. device_model device's model name in ASCII characters. It is a product model name provided by the manufacturer. device_category device's category name in ASCII characters, such as TV, refrigerator, air conditioner, smartphone, tablet, light, and meter. mic_loc device's micro-location, such as refrigerator. mac_loc device's macro-location, such as kitchen. domain_name DNS domain name that is encoded according to the specification of "Representation and use of domain name" of RFC 3315. Jeong & Park Expires March 5, 2015 [Page 8] Internet-Draft Homenet Device Name Autoconf September 2014 7. Security Considerations This document shares all the security issues of the NI protocol that are specified in the "Security Considerations" section of [RFC4620]. 8. Acknowledgements This work was partly supported by the ICT R&D program of MSIP/IITP [10041244, SmartTV 2.0 Software Platform] and ETRI. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, September 2007. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 6106, November 2010. [RFC3315] Droms, R., Ed., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004. [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003. 9.2. Informative References [RFC4620] Crawford, M. and B. Haberman, Ed., "IPv6 Node Information Queries", RFC 4620, August 2006. [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Jeong & Park Expires March 5, 2015 [Page 9] Internet-Draft Homenet Device Name Autoconf September 2014 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. [IEEE-802.11] IEEE Std 802.11, "Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", March 2012. [IEEE-802.11a] IEEE Std 802.11a, "Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications: High-speed Physical Layer in the 5 GHZ Band", September 1999. [IEEE-802.11b] IEEE Std 802.11b, "Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications: Higher-Speed Physical Layer Extension in the 2.4 GHz Band", September 1999. [IEEE-802.11g] IEEE P802.11g/D8.2, "Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications: Further Higher Data Rate Extension in the 2.4 GHz Band", April 2003. [IEEE-802.11n] IEEE P802.11n/D9.0, "Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications Amendment 5: Enhancements for Higher Throughput", March 2009. Authors' Addresses Jaehoon Paul Jeong Sungkyunkwan University 2066 Seobu-Ro, Jangan-Gu Suwon, Gyeonggi-Do 440-746 Republic of Korea Phone: +82 31 299 4957 Fax: +82 31 290 5119 EMail: pauljeong@skku.edu URI: http://cpslab.skku.edu/people-jaehoon-jeong.php Jeong & Park Expires March 5, 2015 [Page 10] Internet-Draft Homenet Device Name Autoconf September 2014 Jung-Soo Park Electronics and Telecommunications Research Institute 218 Gajeong-Ro, Yuseong-Gu Daejeon, 305-700 Republic of Korea Phone: +82 42 860 6514 EMail: pjs@etri.re.kr Jeong & Park Expires March 5, 2015 [Page 11]