DNS Name Autoconfiguration for Internet of Things Devices
draft-jeong-its-iot-dns-autoconf-00
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 , Sejun Lee , Park Jung-Soo | ||
| Last updated | 2016-03-17 | ||
| 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-its-iot-dns-autoconf-00
Network Working Group J. Jeong
Internet-Draft Sungkyunkwan University
Intended status: Standards Track S. Lee
Expires: September 18, 2016 KETI
J. Park
ETRI
March 17, 2016
DNS Name Autoconfiguration for Internet of Things Devices
draft-jeong-its-iot-dns-autoconf-00
Abstract
This document specifies an autoconfiguration scheme for the global
(or local) DNS names of Internet of Things (IoT) devices, such as
sensors, actuators, and in-vehicle units. By this scheme, the DNS
name of an IoT device can be autoconfigured with the device's
category and model in wired and wireless target networks (e.g.,
vehicle, road network, home, office, shopping mall, and smart grid).
This DNS name lets IoT users (e.g., drivers, passengers, home
residents, and customers) in the Internet (or local network) easily
identify each device for monitoring and remote-controlling it in the
target 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 18, 2016.
Jeong, et al. Expires September 18, 2016 [Page 1]
Internet-Draft IoT DNS Name Autoconf March 2016
Copyright Notice
Copyright (c) 2016 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Applicability Statements . . . . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. DNS Name Autoconfiguration . . . . . . . . . . . . . . . . . . 5
5.1. DNS Name Format . . . . . . . . . . . . . . . . . . . . . 5
5.2. DNS Name Format with Object Identifier . . . . . . . . . . 6
5.3. Procedure of DNS Name Autoconfiguration . . . . . . . . . 7
5.3.1. DNS Name Generation . . . . . . . . . . . . . . . . . 7
5.3.2. DNS Name Collection . . . . . . . . . . . . . . . . . 8
5.3.3. DNS Name Retrieval . . . . . . . . . . . . . . . . . . 9
6. Location-Aware DNS Name Configuration . . . . . . . . . . . . 9
6.1. Macro-Location-Aware DNS Name . . . . . . . . . . . . . . 9
6.2. Micro-Location-Aware DNS Name . . . . . . . . . . . . . . 10
6.3. Location-Aware DNS Name with Object Identifier . . . . . . 11
7. DNS Name Management for Mobile IoT Devices . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 13
Jeong, et al. Expires September 18, 2016 [Page 2]
Internet-Draft IoT DNS Name Autoconf March 2016
1. Introduction
Many Internet of Things (IoT) devices (e.g., sensors, actuators, and
in-vehicle units) 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 vehicles, road
infrastructure devices (e.g., road-side unit, traffic light, and
loop-detector), appliances (e.g., television, refrigerator, air
conditioner, and washing machine), and smart devices (smartphone and
tablet). They are placed in environments (e.g., vehicle, road
network, home, office, shopping mall, and smart grid) 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., in-vehicle units, light sensor,
meter, and fire detector) and actuators (e.g., vehicle engine, signal
light, street light, and room temperature controller). They are
installed for the easy management of environments (e.g., vehicle,
road network, 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., address prefixes, 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.
Multicast DNS (mDNS) in [RFC6762] can provide DNS service for
networked devices on a local link (e.g., home network and office
network) without any conventional recursive DNS server. mDNS also
supports the autoconfiguration of a device's DNS name without the
intervention of the user. mDNS aims at the DNS naming service for the
local DNS names of the networked devices on the local link rather
than the DNS naming service for the global DNS names of such devices
in the Internet. However, for IoT devices accessible from the
Internet, mDNS cannot be used. Thus, a new autoconfiguration scheme
becomes required for the global DNS names of IoT devices.
This document proposes an autoconfiguration scheme for the global (or
local) DNS names of IoT devices. Since an autoconfigured DNS name
Jeong, et al. Expires September 18, 2016 [Page 3]
Internet-Draft IoT DNS Name Autoconf March 2016
contains the device category and model of a device, IoT users in the
Internet (or local network) 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 (e.g.,
smartphone and tablet) by resolving its DNS name into the
corresponding IPv6 address.
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], Dedicated Short-Range Communications (DSRC)
[IEEE-802.11p], 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., vehicle,
road-side unit, 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].
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., vehicle, road-side unit, 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].
Jeong, et al. Expires September 18, 2016 [Page 4]
Internet-Draft IoT DNS Name Autoconf March 2016
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
autoconfiguration in the coexistence of RA and DHCP.
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: IoT 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, et al. Expires September 18, 2016 [Page 5]
Internet-Draft IoT DNS Name Autoconf March 2016
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 vehicle, road-side unit, engine, gear,
smart TV, refrigerator, air conditioner,
smartphone, tablet, light, and meter.
domain_name domain name that represents a DNS domain for
the network having the IoT devices.
Note each subdomain (i.e., unique_id, device_model, device_category,
and domain_name) in the domain name format in Figure 1 is expressed
using the name syntax described in [RFC1035].
5.2. DNS Name Format with Object Identifier
A DNS name for an IoT device can have the following format with
object identifier (OID), which is defined in [oneM2M-OID], as in
Figure 2:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unique_id.object_identifier.OID.domain_name |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: IoT Device DNS Name Format with OID
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.
object_identifier device's object identifier that consists of a
higher arc, that is, M2M node indication ID (
i.e., the concatenation of the managing
organization, administration, data country
code, and M2M node) and a sequence of four
arcs (i.e., manufacturer ID, model ID, serial
ID, and expanded ID) as defined in
[oneM2M-OID]. The fields are seperated by an
underscore '_'.
OID subdomain for the keyword of OID to indicate
that object_identifier is used.
Jeong, et al. Expires September 18, 2016 [Page 6]
Internet-Draft IoT DNS Name Autoconf March 2016
domain_name domain name that represents a DNS domain for
the network having the IoT devices.
Note each subdomain (i.e., unique_id, object_identifier, OID, and
domain_name) in the domain name format in Figure 2 is expressed using
the name syntax described in [RFC1035].
5.3. 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.3.1. DNS Name Generation
When as an IPv6 host a device receives a DNSSL option through either
RA or DHCPv6, it checks the validity of 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 (i.e., device category and device
model) and a selected identifier (as unique_id) that is
considered unique, as shown in Figure 1.
2. The host constructs an IPv6 unicast address as a tentative
address with a 64-bit network prefix and the last 64 bits of the
MD5 hashed value of the above DNS name.
3. The host constructs the solicited-node multicast address in
[RFC4861] corresponding to the tentative IPv6 address.
4. The host performs Duplicate Address Detection (DAD) for the IPv6
address with the solicited-node multicast address [RFC4861]
[RFC4862].
5. If there is no response from the DAD, the host sets the IPv6
tentative address as its IPv6 unicast address and regards the
constructed DNS name as unique on the local link. Otherwise,
since the DAD fails because of DNS name conflict, go to Step 1
for a new DNS name generation with another identifier for
unique_id.
6. Since 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. Also, the host joins the
solicited-node multicast address for the verified DNS name in
order to prevent other hosts from using this DNS name.
Jeong, et al. Expires September 18, 2016 [Page 7]
Internet-Draft IoT DNS Name Autoconf March 2016
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 along with the
IPv6 unicast autoconfiguration corresponding to the DNS name.
5.3.2. DNS Name Collection
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 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 scope
multicast address (e.g., all-nodes multicast address, FF02::1) SHOULD
be defined for device DNS name collection such 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 its DNS name 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 resolves the
DNS names into the corresponding IPv6 addresses by NI protocol
[RFC4620] with the ICMPv6 Code 1 of NI Query. This code indicates
that the Data field of the NI Query has the DNS name of an IoT
device. The IoT device that receives this NI query sends the
collector an NI Reply with its IPv6 address in the Data field.
For DNS name resolution service, the collector can register the
pair(s) of DNS name and IPv6 address for each IPv6 host into an
appropriate designated DNS server for the DNS domain suffix of the
DNS name. It is assumed that the collector is configured to register
DNS names into the designated DNS server in a secure way based on
DNSSEC [RFC4033][RFC6840]. This registration of the DNS name and
IPv6 address can be performed by DNS dynamic update [RFC2136].
Jeong, et al. Expires September 18, 2016 [Page 8]
Internet-Draft IoT DNS Name Autoconf March 2016
Before registering the DNS name into the designated DNS server, the
collector SHOULD verify the uniqueness of the DNS name in the
intended DNS domain by sending a DNS query for the resolution of the
DNS name. If there is no corresponding IPv6 address for the queried
DNS name, the collector registers the DNS name and the corresponding
IPv6 address into the designated DNS server. On the other hand, if
there is such a corresponding IPv6 address, the DNS name is regarded
as duplicate (i.e., not unique), and so the corresponder notifies the
corresponding IoT device with the duplicate DNS name of an error
message of DNS name duplication using NI protocol. When an IoT
device receives such a DNS name duplication error, it needs to
construct a new DNS name and repeats the procedure of device DNS name
generation along with the uniqueness test of the device DNS name in
its subnet.
The two separate procedures of the DNS name collection and IPv6
address resolution in the above NI protocol can be consolidated into
a single collection for the pairs of DNS names and the corresponding
IPv6 addresses. For such an optimization, a new ICMPv6 Code (e.g.,
4) is defined for the NI Query to query the pair of a DNS name and
the corresponding IPv6 address. With this code, the collector can
collect the pairs of each IoT device's DNS name and IPv6 address in
one NI query message rather than two NI query messages.
5.3.3. DNS Name Retrieval
A smart device like smartphone can retrieve the DNS names of IoT
devices by contacting a global (or 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 target network, such as home network and office network. With this
information, the user can monitor and control the IoT devices in the
Internet (or local network).
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.
6.1. Macro-Location-Aware DNS Name
If location information (such as cross area, intersection, and road
segment in a road network) 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 vehicle, smartphone, and tablet). The
physical location of the device is defined as macro-location for DNS
Jeong, et al. Expires September 18, 2016 [Page 9]
Internet-Draft IoT DNS Name Autoconf March 2016
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 3. 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, edge, or corner in a
place that is specified by macro-location. For example, assume that
a loop-detector is located in the start or end position of a road
segment. If the DNS name for the loop-detector contains the start or
end position of the living room, a road network administrator 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 3. 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 3:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unique_id.device_model.device_category.mic_loc.mac_loc.domain_name|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: 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 vehicle, road-side unit, engine, gear,
smart TV, refrigerator, air conditioner,
Jeong, et al. Expires September 18, 2016 [Page 10]
Internet-Draft IoT DNS Name Autoconf March 2016
smartphone, tablet, light, and meter.
mic_loc device's micro-location, such as center, edge,
and corner.
mac_loc device's macro-location, such as road segment.
domain_name domain name that represents a DNS domain for
the network having the IoT devices.
Note each subdomain (e.g., mic_loc and mac_loc) in the domain name
format in Figure 3 is expressed using the name syntax described in
[RFC1035].
6.3. Location-Aware DNS Name with Object Identifier
Instead of device_model and device_category, object_identifier can be
used for a location-aware DNS name as specified in Figure 4:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unique_id.object_identifier.OID.mic_loc.mac_loc.domain_name |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Location-Aware Device DNS Name Format with Object
Identifier
7. DNS Name Management for Mobile IoT Devices
Some IoT devices can have mobility, such as vehicle, smartphone,
tablet, laptop computer, and cleaning robot. This mobility allows
the IoT devices to move from a subnet to another subnet where subnets
can have different domain suffixes, such as
coordinate.road_segment.road, coordinate.intersection.road,
living_room.home and garage.home. The DNS name change (or addition)
due to the mobility should be considered.
To deal with DNS name management in mobile environments, whenever an
IoT device enters a new subnet and receives DNS suffix domain names,
it generates its new DNS names and registers them into a designated
DNS server, specified by RDNSS option.
When the IoT device recognizes the movement to another subnet, it can
delete its previous DNS name(s) from the DNS server having the DNS
name(s), using DNS dynamic update [RFC2136]. For at least one DNS
name to remain in a DNS server for the location management in Mobile
IPv6 [RFC6275], the IoT device does not delete its default DNS name
in its home network in Mobile IPv6.
Jeong, et al. Expires September 18, 2016 [Page 11]
Internet-Draft IoT DNS Name Autoconf March 2016
8. Security Considerations
This document shares all the security issues of the NI protocol that
are specified in the "Security Considerations" section of [RFC4620].
To prevent the disclosure of location information for privacy
concern, the subdomains related to location can be encrypted by a
shared key or public-and-private keys. For example, a DNS name of
vehicle1.coordinate1.road_segment.road can be represented as
vehicle1.xxx.yyy.road where xxx is a string of the encrypted
representation of the coordinate (denoted as coordinate1) in the
road_segment and yyy is a string of the encrypted representation of
the subdomain road_segment.
9. Acknowledgements
This document was supported by Institute for Information &
communications Technology Promotion (IITP) grant funded by the Korea
government (MSIP) [10041244, Smart TV 2.0 Software Platform].
10. References
10.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., Bound, J., Volz, B., Lemon, T.,
Perkins, C., and M. Carney, "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.
Jeong, et al. Expires September 18, 2016 [Page 12]
Internet-Draft IoT DNS Name Autoconf March 2016
[RFC3646] Droms, R., Ed., "DNS Configuration options for
Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3646, December 2003.
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification", RFC 1035, November 1987.
[RFC4033] Arends, R., Ed., Austein, R., Larson, M., Massey,
D., and S. Rose, "DNS Security Introduction and
Requirements", RFC 4033, March 2005.
[RFC6840] Weiler, S., Ed. and D. Blacka, Ed., "Clarifications
and Implementation Notes for DNS Security (DNSSEC)",
RFC 6840, February 2013.
10.2. Informative References
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS",
RFC 6762, February 2013.
[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.
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko,
"Mobility Support in IPv6", RFC 6275, July 2011.
[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
Jeong, et al. Expires September 18, 2016 [Page 13]
Internet-Draft IoT DNS Name Autoconf March 2016
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.11p] IEEE Std 802.11p, "Part 11: Wireless LAN Medium
Access Control (MAC) and Physical Layer (PHY)
Specifications - Amendment 6: Wireless Access in
Vehicular Environments", July 2010.
[IEEE-802.15.1] IEEE Std 802.15.1, "Part 15.1: Wireless Medium
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.
[oneM2M-OID] oneM2M, "Object Identifier based M2M Device
Identification Scheme", February 2014.
Authors' Addresses
Jaehoon Paul Jeong
Department of Software
Sungkyunkwan University
2066 Seobu-Ro, Jangan-Gu
Suwon, Gyeonggi-Do 16419
Republic of Korea
Phone: +82 31 299 4957
Fax: +82 31 290 7996
EMail: pauljeong@skku.edu
URI: http://iotlab.skku.edu/people-jaehoon-jeong.php
Jeong, et al. Expires September 18, 2016 [Page 14]
Internet-Draft IoT DNS Name Autoconf March 2016
Sejun Lee
Korea Electronics Technology Institute
25, Saenari-Ro, Bundang-Gu
Seongnam-Si, Gyeonggi-Do 13509
Republic of Korea
Phone: +82 31 789 7535
EMail: prosejun14@gmail.com
Jung-Soo Park
Electronics and Telecommunications Research Institute
218 Gajeong-Ro, Yuseong-Gu
Daejeon, 34129
Republic of Korea
Phone: +82 42 860 6514
EMail: pjs@etri.re.kr
Jeong, et al. Expires September 18, 2016 [Page 15]