idnits 2.17.1 draft-jeong-ipwave-iot-dns-autoconf-01.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 233 has weird spacing: '...ntifier devic...' == Line 418 has weird spacing: '...ntifier devic...' -- The document date (October 30, 2017) is 2369 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 6106 (Obsoleted by RFC 8106) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3736 (Obsoleted by RFC 8415) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Jeong 3 Internet-Draft Sungkyunkwan University 4 Intended status: Standards Track S. Lee 5 Expires: May 3, 2018 Ericsson-LG 6 J. Park 7 ETRI 8 October 30, 2017 10 DNS Name Autoconfiguration for Internet of Things Devices 11 draft-jeong-ipwave-iot-dns-autoconf-01 13 Abstract 15 This document specifies an autoconfiguration scheme for device 16 discovery and service discovery. Through the device discovery, this 17 document supports the global (or local) DNS naming of Internet of 18 Things (IoT) devices, such as sensors, actuators, and in-vehicle 19 units. By this scheme, the DNS name of an IoT device can be 20 autoconfigured with the device's model information in wired and 21 wireless target networks (e.g., vehicle, road network, home, office, 22 shopping mall, and smart grid). Through the service discovery, IoT 23 users (e.g., drivers, passengers, home residents, and customers) in 24 the Internet (or local network) can easily identify each device for 25 monitoring and remote-controlling it in a target network. 27 Status of This Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt. 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 This Internet-Draft will expire on May 3, 2018. 50 Copyright Notice 52 Copyright (c) 2017 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Applicability Statements . . . . . . . . . . . . . . . . . 4 69 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 70 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 5. DNS Name Autoconfiguration . . . . . . . . . . . . . . . . . . 5 73 5.1. DNS Name Format with Object Identifier . . . . . . . . . . 5 74 5.2. Procedure of DNS Name Autoconfiguration . . . . . . . . . 6 75 5.2.1. DNS Name Generation . . . . . . . . . . . . . . . . . 6 76 5.2.2. DNS Name Collection . . . . . . . . . . . . . . . . . 7 77 5.2.3. DNS Name Retrieval . . . . . . . . . . . . . . . . . . 9 78 6. Location-Aware DNS Name Configuration . . . . . . . . . . . . 9 79 7. Macro-Location-Aware DNS Name . . . . . . . . . . . . . . . . 10 80 8. Micro-Location-Aware DNS Name . . . . . . . . . . . . . . . . 10 81 9. DNS Name Management for Mobile IoT Devices . . . . . . . . . . 11 82 10. Service Discovery for IoT Devices . . . . . . . . . . . . . . 11 83 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 84 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 85 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 86 13.1. Normative References . . . . . . . . . . . . . . . . . . . 12 87 13.2. Informative References . . . . . . . . . . . . . . . . . . 13 88 Appendix A. Changes from 89 draft-jeong-ipwave-iot-dns-autoconf-00 . . . . . . . 15 91 1. Introduction 93 Many Internet of Things (IoT) devices (e.g., sensors, actuators, and 94 in-vehicle units) have begun to have wireless communication 95 capability (e.g., WiFi, Bluetooth, and ZigBee) for monitoring and 96 remote-controlling in a local network or the Internet. According to 97 the capacity, such IoT devices can be categorized into high-capacity 98 devices and low-capacity devices. High-capacity devices have a high- 99 power processor and a large storage, such as vehicles, road 100 infrastructure devices (e.g., road-side unit, traffic light, and 101 loop-detector), appliances (e.g., television, refrigerator, air 102 conditioner, and washing machine), and smart devices (smartphone and 103 tablet). They are placed in environments (e.g., vehicle, road 104 network, home, office, shopping mall, and smart grid) for the direct 105 use for human users, and they require the interaction with human 106 users. Low-capacity devices have a low-power processor and a small 107 storage, such as sensors (e.g., in-vehicle units, light sensor, 108 meter, and fire detector) and actuators (e.g., vehicle engine, signal 109 light, street light, and room temperature controller). They are 110 installed for the easy management of environments (e.g., vehicle, 111 road network, home, office, store, and factory), and they do not 112 require the interaction with human users. 114 For the Internet connectivity of IoT devices, a variety of parameters 115 (e.g., address prefixes, default routers, and DNS servers) can be 116 automatically configured by Neighbor Discovery (ND) for IP Version 6, 117 IPv6 Stateless Address Autoconfiguration, and IPv6 Router 118 Advertisement (RA) Options for DNS Configuration [RFC4861][RFC4862] 119 [RFC6106]. 121 For these IoT devices, the manual configuration of DNS names will be 122 cumbersome and time-consuming as the number of them increases rapidly 123 in a network. It will be good for such DNS names to be automatically 124 configured such that they are readable to human users. 126 Multicast DNS (mDNS) in [RFC6762] can provide DNS service for 127 networked devices on a local link (e.g., home network and office 128 network) without any conventional recursive DNS server. mDNS also 129 supports the autoconfiguration of a device's DNS name without the 130 intervention of the user. mDNS aims at the DNS naming service for the 131 local DNS names of the networked devices on the local link rather 132 than the DNS naming service for the global DNS names of such devices 133 in the Internet. However, for IoT devices accessible from the 134 Internet, mDNS cannot be used. Thus, a new autoconfiguration scheme 135 becomes required for the global DNS names of IoT devices. 137 This document proposes an autoconfiguration scheme for the global (or 138 local) DNS names of IoT devices. Since an autoconfigured DNS name 139 contains the model identifier (ID) of a device, IoT users in the 140 Internet (or local network) can easily identify the device. With 141 this model ID, they will be able to monitor and remote-control each 142 device with mobile smart devices (e.g., smartphone and tablet) by 143 resolving its DNS name into the corresponding IPv6 address. 145 1.1. Applicability Statements 147 It is assumed that IoT devices have networking capability through 148 wired or wireless communication media, such as Ethernet [IEEE-802.3], 149 WiFi [IEEE-802.11][IEEE-802.11a][IEEE-802.11b][IEEE-802.11g] 150 [IEEE-802.11n], Dedicated Short-Range Communications (DSRC) 151 [IEEE-802.11p], Bluetooth [IEEE-802.15.1], and ZigBee [IEEE-802.15.4] 152 in a local area network (LAN) or personal area network (PAN). 154 Also, it is assumed that each IoT device has a factory configuration 155 (called device configuration) having device model information by 156 manufacturer ID and model ID (e.g., vehicle, road-side unit, smart 157 TV, smartphone, tablet, and refrigerator). This device configuration 158 can be read by the device for DNS name autoconfiguration. 160 2. Requirements Language 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 164 document are to be interpreted as described in RFC 2119 [RFC2119]. 166 3. Terminology 168 This document uses the terminology described in [RFC4861] and 169 [RFC4862]. In addition, four new terms are defined below: 171 o Device Configuration: A factory configuration that has device 172 model information by manufacturer ID and model ID (e.g., vehicle, 173 road-side unit, smart TV, smartphone, tablet, and refrigerator). 175 o DNS Search List (DNSSL): The list of DNS suffix domain names used 176 by IPv6 hosts when they perform DNS query searches for short, 177 unqualified domain names [RFC6106]. 179 o DNSSL Option: IPv6 RA option to deliver the DNSSL information to 180 IPv6 hosts [RFC6106]. 182 4. Overview 184 This document specifies an autoconfiguration scheme for an IoT device 185 using device configuration and DNS search list. Device configuration 186 has device model information (e.g., device's manufacturer and model). 188 DNS search list has DNS suffix domain names that represent the DNS 189 domains of a network having the IoT device [RFC6106]. 191 As an IPv6 host, the IoT device can obtain DNS search list through 192 IPv6 Router Advertisement (RA) with DNS Search List (DNSSL) Option 193 [RFC4861][RFC6106] or DHCPv6 with Domain Search List Option 194 [RFC3315][RFC3736][RFC3646]. 196 The IoT device can construct its DNS name with the concatenation of 197 manufacturer ID, model ID, and domain name. Since there exist more 198 than one device with the same model, the DNS name should have a 199 unique identification (e.g., unique ID or serial ID) to differentiate 200 multiple devices with the same model. 202 Since both RA and DHCPv6 can be simultaneously used for the parameter 203 configuration for IPv6 hosts, this document considers the DNS name 204 autoconfiguration in the coexistence of RA and DHCP. 206 5. DNS Name Autoconfiguration 208 The DNS name autoconfiguration for an IoT device needs the 209 acquisition of DNS search list through either RA [RFC6106] or DHCPv6 210 [RFC3646]. Once the DNS search list is obtained, the IoT device 211 autonomously constructs its DNS name(s) with the DNS search list and 212 its device information. 214 5.1. DNS Name Format with Object Identifier 216 A DNS name for an IoT device can have the following format with 217 object identifier (OID), which is defined in [oneM2M-OID], as in 218 Figure 1: 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | unique_id.object_identifier.OID.domain_name | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 Figure 1: IoT Device DNS Name Format with OID 226 Fields: 228 unique_id unique identifier to guarantee the uniqueness 229 of the DNS name in ASCII characters. The 230 identifier MAY be alphanumeric with readability, 231 e.g., product name plus a sequence number. 233 object_identifier device's object identifier that consists of a 234 higher arc, that is, M2M node indication ID ( 235 i.e., the concatenation of the managing 236 organization, administration, data country 237 code, and M2M node) and a sequence of four 238 arcs (i.e., manufacturer ID, model ID, serial 239 ID, and expanded ID) as defined in 240 [oneM2M-OID]. The fields are seperated by an 241 underscore '_'. 243 OID subdomain for the keyword of OID to indicate 244 that object_identifier is used. 246 domain_name domain name that represents a DNS domain for 247 the network having the IoT devices. 249 Note each subdomain (i.e., unique_id, object_identifier, OID, and 250 domain_name) in the domain name format in Figure 1 is expressed using 251 the name syntax described in [RFC1035]. 253 5.2. Procedure of DNS Name Autoconfiguration 255 The procedure of DNS name autoconfiguration is performed through a 256 DNSSL option delivered by either RA [RFC6106] or DHCPv6 [RFC3646]. 258 5.2.1. DNS Name Generation 260 When as an IPv6 host a device receives a DNSSL option through either 261 RA or DHCPv6, it checks the validity of the DNSSL option. If the 262 option is valid, the IPv6 host performs the DNS name 263 autoconfiguration with each DNS suffix domain name in the DNSSL 264 option as follows: 266 1. The host constructs its DNS name with the DNS suffix domain name 267 along with device configuration (i.e., manufacturer ID, model ID, 268 and serial ID) and a selected identifier (as unique_id) that is 269 considered unique, which is human-friendly, as shown in Figure 1. 271 2. The host constructs an IPv6 unicast address as a tentative 272 address with a 64-bit network prefix and the last 64 bits of the 273 MD5 hashed value of the above DNS name. 275 3. The host constructs the solicited-node multicast address in 276 [RFC4861] corresponding to the tentative IPv6 address. 278 4. The host performs Duplicate Address Detection (DAD) for the IPv6 279 address with the solicited-node multicast address [RFC4861] 280 [RFC4862]. 282 5. If there is no response from the DAD, the host sets the IPv6 283 tentative address as its IPv6 unicast address and regards the 284 constructed DNS name as unique on the local link. Otherwise, 285 since the DAD fails because of DNS name conflict, go to Step 1 286 for a new DNS name generation with another identifier for 287 unique_id. 289 6. Since the DNS name is proven to be unique, it is used as the 290 device's DNS name and the DNS autoconfiguration is done for the 291 given DNS suffix domain name. Also, the host joins the 292 solicited-node multicast address for the verified DNS name in 293 order to prevent other hosts from using this DNS name. 295 When the DNS search list has more than one DNS suffix domain name, 296 the IPv6 host repeats the above procedure until all of the DNS 297 suffixes are used for the DNS name autoconfiguration along with the 298 IPv6 unicast autoconfiguration corresponding to the DNS name. 300 5.2.2. DNS Name Collection 302 Once as IPv6 hosts the devices have autoconfigured their DNS names, 303 as a collector, any IPv6 node (i.e., router or host) in the same 304 subnet can collect the device DNS names using IPv6 Node Information 305 (NI) protocol [RFC4620]. 307 For a collector to collect the device DNS names without any prior 308 node information, a new NI query needs to be defined. That is, a new 309 ICMPv6 Code (e.g., 3) SHOULD be defined for the collection of the 310 IPv6 host DNS names. The Data field is not included in the ICMPv6 311 header since the NI query is for all the IPv6 hosts in the same 312 subnet. The Qtype field for NI type is set to 2 for Node Name. 314 The query SHOULD be transmitted by the collector to a link-local 315 multicast address for this NI query. Assume that a link-local scope 316 multicast address (e.g., all-nodes multicast address, FF02::1) SHOULD 317 be defined for device DNS name collection such that all the IPv6 318 hosts join this link-local multicast address for the device DNS name 319 collection service. 321 When an IPv6 host receives this query sent by the collector in 322 multicast, it transmits its Reply with its DNS name with a random 323 interval between zero and Query Response Interval, as defined by 324 Multicast Listener Discovery Version 2 [RFC3810]. This randomly 325 delayed Reply allows the collector to collect the device DNS names 326 with less frame collision probability by spreading out the Reply time 327 instants. 329 After the collector collects the device DNS names, it resolves the 330 DNS names into the corresponding IPv6 addresses by NI protocol 331 [RFC4620] with the ICMPv6 Code 1 of NI Query. This code indicates 332 that the Data field of the NI Query has the DNS name of an IoT 333 device. The IoT device that receives this NI query sends the 334 collector an NI Reply with its IPv6 address in the Data field. 336 For DNS name resolution service, the collector can register the 337 pair(s) of DNS name and IPv6 address for each IPv6 host into an 338 appropriate designated DNS server for the DNS domain suffix of the 339 DNS name. It is assumed that the collector is configured to register 340 DNS names into the designated DNS server in a secure way based on 341 DNSSEC [RFC4033][RFC6840]. This registration of the DNS name and 342 IPv6 address can be performed by DNS dynamic update [RFC2136]. 343 Before registering the DNS name into the designated DNS server, the 344 collector SHOULD verify the uniqueness of the DNS name in the 345 intended DNS domain by sending a DNS query for the resolution of the 346 DNS name. If there is no corresponding IPv6 address for the queried 347 DNS name, the collector registers the DNS name and the corresponding 348 IPv6 address for each IPv6 host into the designated DNS server. On 349 the other hand, if there is such a corresponding IPv6 address, the 350 DNS name is regarded as duplicate (i.e., not unique), and so the 351 corresponder notifies the corresponding IoT device with the duplicate 352 DNS name of an error message of DNS name duplication using NI 353 protocol. When an IoT device receives such a DNS name duplication 354 error, it needs to construct a new DNS name and repeats the procedure 355 of device DNS name generation along with the uniqueness test of the 356 device DNS name in its subnet. 358 The two separate procedures of the DNS name collection and IPv6 359 address resolution in the above NI protocol can be consolidated into 360 a single collection for the pairs of DNS names and the corresponding 361 IPv6 addresses. For such an optimization, a new ICMPv6 Code (e.g., 362 4) is defined for the NI Query to query the pair of a DNS name and 363 the corresponding IPv6 address. With this code, the collector can 364 collect the pairs of each IoT device's DNS name and IPv6 address in 365 one NI query message rather than two NI query messages. 367 For DNS name collection for IoT devices as IPv6 hosts, DHCPv6 368 [RFC3315] can be used instead of the NI protocol. For this purpose, 369 a new DHCP option (called DNSNA option) needs to be defined to 370 collect the pair of a DNS name and the corresponding IPv6 address of 371 an IoT device. As a DNS information collector, a DHCPv6 server (or a 372 router running a DHCPv6 server) sends a request message for the DHCP 373 DNSNA option to IoT devices as its DHCPv6 clients under its address 374 pool. The clients respond to this request message by sending the 375 DHCPv6 server a reply message with their DNS information. Thus, the 376 DHCPv6 server can collect the pairs of DNS names and the 377 corresponding IPv6 addresses of the IoT devices. Then, as a 378 collector, the DHCPv6 server can register the DNS names and the 379 corresponding IPv6 addresses of IoT devices into the designated DNS 380 server. 382 5.2.3. DNS Name Retrieval 384 A smart device like smartphone can retrieve the DNS names of IoT 385 devices by contacting a global (or local) DNS server having the IoT 386 device DNS names. If the smart device can retrieve the zone file 387 with the DNS names, it can display the information of IoT devices in 388 a target network, such as home network and office network. With this 389 information, the user can monitor and control the IoT devices in the 390 Internet (or local network). 392 6. Location-Aware DNS Name Configuration 394 If the DNS name of an IoT device includes location information, it 395 allows users to easily identify the physical location of each device. 396 This document proposes the representation of a location in a DNS 397 name. In this document, the location in a DNS name consists of two 398 levels for a detailed location specification, such as macro-location 399 for a large area and micro-location for a small area. 401 To denote both macro-location (i.e., mac_loc) and micro-location 402 (i.e., mic_loc) into a DNS name, the following format is described as 403 in Figure 2: 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | unique_id.object_identifier.OID.mic_loc.mac_loc.LOC.domain_name | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 Figure 2: Location-Aware Device DNS Name Format 411 Fields: 413 unique_id unique identifier to guarantee the uniqueness 414 of the DNS name in ASCII characters. The 415 identifier MAY be alphanumeric with readability, 416 such as product name plus a sequence number. 418 object_identifier device's object identifier that consists of a 419 higher arc, that is, M2M node indication ID ( 420 i.e., the concatenation of the managing 421 organization, administration, data country 422 code, and M2M node) and a sequence of four 423 arcs (i.e., manufacturer ID, model ID, serial 424 ID, and expanded ID) as defined in 425 [oneM2M-OID]. The fields are seperated by an 426 underscore '_'. 428 OID subdomain for the keyword of OID to indicate 429 that object_identifier is used. 431 mic_loc device's micro-location, such as center, edge, 432 and corner. 434 mac_loc device's macro-location, such as road segment. 436 LOC subdomain for the keyword of LOC to indicate 437 that mac_loc and mic_loc are used. 439 domain_name domain name that represents a DNS domain for 440 the network having the IoT devices. 442 Note each subdomain (e.g., mic_loc and mac_loc) in the domain name 443 format in Figure 2 is expressed using the name syntax described in 444 [RFC1035]. 446 7. Macro-Location-Aware DNS Name 448 If location information (such as cross area, intersection, and road 449 segment in a road network) is available to an IoT device, a keyword, 450 coordinate, or location ID for the location information can be used 451 to construct a DNS name as subdomain name. This location information 452 lets users track the position of mobile devices (such as vehicle, 453 smartphone, and tablet). The physical location of the device is 454 defined as macro-location for DNS naming. 456 A subdomain name for macro-location (denoted as mac_loc) MAY be 457 placed between micro-location (denoted as mic_loc) and the keyword 458 LOC of the DNS name format in Figure 2. For the localization of 459 macro-location, a localization scheme for indoor or outdoor can be 460 used [SALA]. 462 8. Micro-Location-Aware DNS Name 464 An IoT device can be located in the center or edge in a place that is 465 specified by macro-location. For example, assume that a loop- 466 detector is located in the start or end position of a road segment. 467 If the DNS name for the loop-detector contains the start or end 468 position of the road segment, a road network administrator can find 469 it easily. In this document, for this DNS naming, the detailed 470 location for an IoT device can be specified as a micro-location 471 subdomain name. 473 A subdomain name for micro-location (denoted as mic_loc) MAY be 474 placed between the keyword OID and macro-location (denoted as 475 mac_loc) of the DNS name format in Figure 2. For the localization of 476 micro-location, a localization scheme for indoor or outdoor can be 477 used [SALA]. 479 9. DNS Name Management for Mobile IoT Devices 481 Some IoT devices can have mobility, such as vehicle, smartphone, 482 tablet, laptop computer, and cleaning robot. This mobility allows 483 the IoT devices to move from a subnet to another subnet where subnets 484 can have different domain suffixes, such as 485 coordinate.road_segment.road, coordinate.intersection.road, 486 living_room.home and garage.home. The DNS name change (or addition) 487 due to the mobility should be considered. 489 To deal with DNS name management in mobile environments, whenever an 490 IoT device enters a new subnet and receives DNS suffix domain names, 491 it generates its new DNS names and registers them into a designated 492 DNS server, specified by RDNSS option. 494 When the IoT device recognizes the movement to another subnet, it can 495 delete its previous DNS name(s) from the DNS server having the DNS 496 name(s), using DNS dynamic update [RFC2136]. For at least one DNS 497 name to remain in a DNS server for the location management in Mobile 498 IPv6 [RFC6275], the IoT device does not delete its default DNS name 499 in its home network in Mobile IPv6. 501 10. Service Discovery for IoT Devices 503 DNS SRV resource record (RR) can be used to support the service 504 discovery of the services provided by IoT devices [RFC2782]. This 505 SRV RR specifies a service name, a transport layer protocol, the 506 corresponding port number, and an IP address of a process running in 507 an IP host as a server to provide a service. An instance for a 508 service can be specified in this SRV RR in DNS-based service 509 discovery [RFC6763]. After the DNS name registration in Section 5.2, 510 IoT devices can register their services in the DNS server via a 511 router with DNS SRV RRs for their services. 513 After the service registration, an IoT user can retrieve services 514 available in his/her target network through service discovery, which 515 can fetch the SRV RRs from the DNS server in the target network. 516 Once (s)he retrieves the list of the SRV RRs, (s)he can remote- 517 monitor or remote-control the devices or their services by the 518 protocol and domain of the servers. 520 11. Security Considerations 522 This document shares all the security issues of the NI protocol that 523 are specified in the "Security Considerations" section of [RFC4620]. 525 To prevent the disclosure of location information for privacy 526 concern, the subdomains related to location can be encrypted by a 527 shared key or public-and-private keys. For example, a DNS name of 528 vehicle1.oid1.OID.coordinate1.road_segment_id1.LOC.road can be 529 represented as vehicle1.oid1.OID.xxx.yyy.LOC.road where vehicle1 is 530 unique ID, oid1 is object ID, xxx is a string of the encrypted 531 representation of the coordinate (denoted as coordinate1) in a road 532 segment, and yyy is a string of the encrypted representation of the 533 road segment ID (denoted as road_segment_id1). Thus, the location of 534 the vehicle1 can be protected from unwanted users by encryption. 536 12. Acknowledgments 538 This work was supported by Basic Science Research Program through the 539 National Research Foundation of Korea (NRF) funded by the Ministry of 540 Education (2017R1D1A1B03035885). This work was supported in part by 541 the Global Research Laboratory Program (2013K1A1A2A02078326) through 542 NRF and the DGIST Research and Development Program (CPS Global 543 Center) funded by the Ministry of Science and ICT. 545 This document has greatly benefited from inputs by Keuntae Lee and 546 Seokhwa Kim. 548 13. References 550 13.1. Normative References 552 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 553 Requirement Levels", BCP 14, RFC 2119, March 1997. 555 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. 556 Soliman, "Neighbor Discovery for IP Version 6 557 (IPv6)", RFC 4861, September 2007. 559 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 560 Stateless Address Autoconfiguration", RFC 4862, 561 September 2007. 563 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. 564 Madanapalli, "IPv6 Router Advertisement Options for 565 DNS Configuration", RFC 6106, November 2010. 567 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., 568 Perkins, C., and M. Carney, "Dynamic Host 569 Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, 570 July 2003. 572 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration 573 Protocol (DHCP) Service for IPv6", RFC 3736, 574 April 2004. 576 [RFC3646] Droms, R., Ed., "DNS Configuration options for 577 Dynamic Host Configuration Protocol for IPv6 578 (DHCPv6)", RFC 3646, December 2003. 580 [RFC1035] Mockapetris, P., "Domain Names - Implementation and 581 Specification", RFC 1035, November 1987. 583 [RFC4033] Arends, R., Ed., Austein, R., Larson, M., Massey, 584 D., and S. Rose, "DNS Security Introduction and 585 Requirements", RFC 4033, March 2005. 587 [RFC6840] Weiler, S., Ed. and D. Blacka, Ed., "Clarifications 588 and Implementation Notes for DNS Security (DNSSEC)", 589 RFC 6840, February 2013. 591 13.2. Informative References 593 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", 594 RFC 6762, February 2013. 596 [RFC4620] Crawford, M. and B. Haberman, Ed., "IPv6 Node 597 Information Queries", RFC 4620, August 2006. 599 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 600 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 602 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. 603 Bound, "Dynamic Updates in the Domain Name System 604 (DNS UPDATE)", RFC 2136, April 1997. 606 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, 607 "Mobility Support in IPv6", RFC 6275, July 2011. 609 [IEEE-802.3] IEEE Std 802.3, "IEEE Standard for Ethernet", 610 December 2012. 612 [IEEE-802.11] IEEE Std 802.11, "Part 11: Wireless LAN Medium 613 Access Control (MAC) and Physical Layer (PHY) 614 Specifications", March 2012. 616 [IEEE-802.11a] IEEE Std 802.11a, "Part 11: Wireless LAN Medium 617 Access Control (MAC) and Physical Layer (PHY) 618 specifications - High-speed Physical Layer in the 5 619 GHZ Band", September 1999. 621 [IEEE-802.11b] IEEE Std 802.11b, "Part 11: Wireless LAN Medium 622 Access Control (MAC) and Physical Layer (PHY) 623 specifications - Higher-Speed Physical Layer 624 Extension in the 2.4 GHz Band", September 1999. 626 [IEEE-802.11g] IEEE P802.11g/D8.2, "Part 11: Wireless LAN Medium 627 Access Control (MAC) and Physical Layer (PHY) 628 specifications - Further Higher Data Rate Extension 629 in the 2.4 GHz Band", April 2003. 631 [IEEE-802.11n] IEEE P802.11n/D9.0, "Part 11: Wireless LAN Medium 632 Access Control (MAC) and Physical Layer (PHY) 633 specifications - Amendment 5: Enhancements for 634 Higher Throughput", March 2009. 636 [IEEE-802.11p] IEEE Std 802.11p, "Part 11: Wireless LAN Medium 637 Access Control (MAC) and Physical Layer (PHY) 638 Specifications - Amendment 6: Wireless Access in 639 Vehicular Environments", July 2010. 641 [IEEE-802.15.1] IEEE Std 802.15.1, "Part 15.1: Wireless Medium 642 Access Control (MAC) and Physical Layer (PHY) 643 specifications for Wireless Personal Area Networks 644 (WPANs)", June 2005. 646 [IEEE-802.15.4] IEEE Std 802.15.4, "Part 15.4: Low-Rate Wireless 647 Personal Area Networks (LR-WPANs)", September 2011. 649 [oneM2M-OID] oneM2M, "Object Identifier based M2M Device 650 Identification Scheme", February 2014. 652 [SALA] Jeong, J., Yeon, S., Kim, T., Lee, H., Kim, S., and 653 S. Kim, "SALA: Smartphone-Assisted Localization 654 Algorithm for Positioning Indoor IoT Devices", 655 Springer Wireless Networks , June 2016. 657 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR 658 for specifying the location of services (DNS SRV)", 659 RFC 2782, February 2000. 661 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 662 Discovery", RFC 6763, February 2013. 664 Appendix A. Changes from draft-jeong-ipwave-iot-dns-autoconf-00 666 The following changes are made from 667 draft-jeong-ipwave-iot-dns-autoconf-00: 669 o In Section 5.2.2, DHCPv6 can be used for DNS name collection of 670 IoT devices instead of IPv6 NI protocol. 672 Authors' Addresses 674 Jaehoon Paul Jeong 675 Department of Software 676 Sungkyunkwan University 677 2066 Seobu-Ro, Jangan-Gu 678 Suwon, Gyeonggi-Do 16419 679 Republic of Korea 681 Phone: +82 31 299 4957 682 Fax: +82 31 290 7996 683 EMail: pauljeong@skku.edu 684 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 686 Sejun Lee 687 Ericsson-LG 688 77, Heungan-Daero 81 Beon-Gil, Dongan-Gu 689 Anyang-Si, Gyeonggi-Do 14117 690 Republic of Korea 692 Phone: +82 31 450 4099 693 EMail: prosejun14@gmail.com 695 Jung-Soo Park 696 Electronics and Telecommunications Research Institute 697 218 Gajeong-Ro, Yuseong-Gu 698 Daejeon, 34129 699 Republic of Korea 701 Phone: +82 42 860 6514 702 EMail: pjs@etri.re.kr