Skip to main content

DNS Name Autoconfiguration for Internet of Things Devices
draft-jeong-homenet-device-name-autoconf-02

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Jaehoon Paul Jeong , Park Jung-Soo
Last updated 2015-03-23
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-jeong-homenet-device-name-autoconf-02
Network Working Group                                           J. Jeong
Internet-Draft                                   Sungkyunkwan University
Intended status: Standards Track                                 J. Park
Expires: September 24, 2015                                         ETRI
                                                          March 23, 2015

       DNS Name Autoconfiguration for Internet of Things Devices
              draft-jeong-homenet-device-name-autoconf-02

Abstract

   This document specifies an autoconfiguration scheme for DNS names of
   Internet of Things (IoT) devices, such as appliances and sensors.  By
   this scheme, the DNS name of an IoT device can be autoconfigured with
   the device's category and model in a network such as home network and
   office network.  This DNS name lets IoT users (e.g., home residents)
   easily identify each device for monitoring and remote-controlling it
   in the 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 September 24, 2015.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Jeong & Park           Expires September 24, 2015               [Page 1]
Internet-Draft          IoT Device Name Autoconf              March 2015

   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.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Applicability Statements . . . . . . . . . . . . . . . . .  3
   2.  Requirements Language  . . . . . . . . . . . . . . . . . . . .  4
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   5.  DNS Name Autoconfiguration . . . . . . . . . . . . . . . . . .  5
     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 . . . . . . . . . . . .  7
       5.2.4.  Retrieval of Device DNS Names  . . . . . . . . . . . .  7
   6.  Location-Aware DNS Name Configuration  . . . . . . . . . . . .  7
     6.1.  Macro-Location-Aware DNS Name  . . . . . . . . . . . . . .  8
     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 . . . . . . . . . . . . . . . . . . 10

Jeong & Park           Expires September 24, 2015               [Page 2]
Internet-Draft          IoT Device Name Autoconf              March 2015

1.  Introduction

   Many Internet of Things (IoT) devices (e.g., appliances and sensors)
   have begun to have wireless communication capability (e.g., WiFi,
   Bluetooth, and ZigBee) for monitoring and remote-controlling in a
   local network or the Internet.  According to the capacity, such IoT
   devices can be categorized into high-capacity devices and low-
   capacity devices.  High-capacity devices have a high-power processor
   and a large storage, such as appliances (e.g., television,
   refrigerator, air conditioner, and washing machine) and smart devices
   (smartphone and tablet).  They are placed in environments (e.g., home
   and office) for the direct use for human users, and they require the
   interaction with human users.  Low-capacity devices have a low-power
   processor and a small storage, such as sensors (e.g., light, meter,
   room temperature controller, and sensors).  They are installed for
   the easy management of environments (e.g., home, office, store, and
   factory), and they do not require the interaction with human users.

   For the Internet connectivity of IoT 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 IoT devices, the manual configuration of DNS names will be
   cumbersome and time-consuming as the number of them increases rapidly
   in a network.  It will be good for such DNS names to be automatically
   configured such that they are readable to human users.

   This document proposes an autoconfiguration scheme for DNS names of
   IoT devices.  Since an autoconfigured DNS name contains the device
   category and model of a device, the users 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 IoT devices have networking capability through
   wired or wireless communication media, such as Ethernet [IEEE-802.3],
   WiFi [IEEE-802.11] [IEEE-802.11a] [IEEE-802.11b][IEEE-802.11g]
   [IEEE-802.11n], Bluetooth [IEEE-802.15.1], and ZigBee [IEEE-802.15.4]
   in a local area network (LAN) or personal area network (PAN).

   Also, it is assumed that each IoT 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

Jeong & Park           Expires September 24, 2015               [Page 3]
Internet-Draft          IoT Device Name Autoconf              March 2015

   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].

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 an IoT 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 the DNS domains of a network having the
   IoT device [RFC6106].

   As an IPv6 host, the IoT 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 IoT 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.

Jeong & Park           Expires September 24, 2015               [Page 4]
Internet-Draft          IoT Device Name Autoconf              March 2015

5.  DNS Name Autoconfiguration

   The DNS name autoconfiguration for an IoT device needs the
   acquisition of DNS search list through either RA [RFC6106] or DHCPv6
   [RFC3646].  Once the DNS search list is obtained, the IoT device
   autonomously constructs its DNS name(s) with the DNS search list and
   its device information.

5.1.  DNS Name Format

   A DNS name for an IoT 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

Jeong & Park           Expires September 24, 2015               [Page 5]
Internet-Draft          IoT Device Name Autoconf              March 2015

   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.

   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 for its device DNS name with a
   64-bit prefix from an RA option (or DHCPv6) and the first 64-bit hash
   value corresponding to the DNS name.  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 (i.e., MD5).  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 three times 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.

Jeong & Park           Expires September 24, 2015               [Page 6]
Internet-Draft          IoT Device Name Autoconf              March 2015

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].

   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].

5.2.4.  Retrieval of Device DNS Names

   A smart device like smartphone can retrieve the DNS names of IoT
   devices by contacting a local DNS server having the IoT device DNS
   names.  If the smart device can retrieve the zone file with the DNS
   names, it can display the information of IoT devices in a local
   network, such as home network.  With this information, the user can
   monitor and control the IoT devices.

6.  Location-Aware DNS Name Configuration

   If the DNS name of an IoT device includes location information, it
   allows users to easily identify the physical location of each device.
   This document proposes the representation of location in a DNS name.

Jeong & Park           Expires September 24, 2015               [Page 7]
Internet-Draft          IoT Device Name Autoconf              March 2015

6.1.  Macro-Location-Aware DNS Name

   If location information (such as living room, kitchen, and bedroom in
   an apartment) is available to an IoT device, a keyword for the
   location can be used to construct a DNS name as subdomain name.  This
   location information lets users 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 (denoted as mac_loc) MAY be
   placed between device_category and domain_name of the DNS name format
   in Figure 2.  A localization scheme for device location is beyond the
   scope of this document.

6.2.  Micro-Location-Aware DNS Name

   An IoT device can be located in the center, wall, or corner in a room
   that is specified by macro-location.  For example, assume that a
   cleaning robot is located in the right-upper corner of a living room.
   If the DNS name for the cleaning robot contains the right-upper
   corner of the living room, a home resident can find it easily.  In
   this document, for this DNS naming, the detailed location for an IoT
   device can be specified as a micro-location subdomain name.

   A subdomain name for micro-location (denoted as mic_loc) MAY be
   placed between device_category and domain_name of the DNS name format
   in Figure 2.  A localization scheme for micro-location is beyond the
   scope of this document.

   To denote both macro-location (i.e., mac_loc) and micro-location
   (i.e., mic_loc) 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.

Jeong & Park           Expires September 24, 2015               [Page 8]
Internet-Draft          IoT Device Name Autoconf              March 2015

     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 center,
                        wall, and corner.

     mac_loc            device's macro-location, such as living room.

     domain_name        DNS domain name that is encoded according to
                        the specification of "Representation and use
                        of domain name" of RFC 3315.

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.

Jeong & Park           Expires September 24, 2015               [Page 9]
Internet-Draft          IoT Device Name Autoconf              March 2015

   [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.

   [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.3]     IEEE Std 802.3, "IEEE Standard for Ethernet",
                    December 2012.

   [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.

   [IEEE-802.15.1]  IEEE Std 802.15.1, "Part 15.1: Wireless Medium

Jeong & Park           Expires September 24, 2015              [Page 10]
Internet-Draft          IoT Device Name Autoconf              March 2015

                    Access Control (MAC) and Physical Layer (PHY)
                    specifications for Wireless Personal Area Networks
                    (WPANs)", June 2005.

   [IEEE-802.15.4]  IEEE Std 802.15.4, "Part 15.4: Low-Rate Wireless
                    Personal Area Networks (LR-WPANs)", September 2011.

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

   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 September 24, 2015              [Page 11]