idnits 2.17.1 draft-jeong-ipwave-iot-dns-autoconf-04.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 241 has weird spacing: '...ntifier devic...' == Line 428 has weird spacing: '...ntifier devic...' -- The document date (October 22, 2018) is 2011 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3736 (Obsoleted by RFC 8415) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPWAVE Working Group J. Jeong 3 Internet-Draft Sungkyunkwan University 4 Intended status: Standards Track S. Lee 5 Expires: April 25, 2019 Ericsson-LG 6 J. Park 7 ETRI 8 October 22, 2018 10 DNS Name Autoconfiguration for Internet of Things Devices 11 draft-jeong-ipwave-iot-dns-autoconf-04 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 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). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on April 25, 2019. 44 Copyright Notice 46 Copyright (c) 2018 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Applicability Statements . . . . . . . . . . . . . . . . 4 63 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 64 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 5. DNS Name Autoconfiguration . . . . . . . . . . . . . . . . . 5 67 5.1. DNS Name Format with Object Identifier . . . . . . . . . 5 68 5.2. Procedure of DNS Name Autoconfiguration . . . . . . . . . 6 69 5.2.1. DNS Name Generation . . . . . . . . . . . . . . . . . 6 70 5.2.2. DNS Name Collection . . . . . . . . . . . . . . . . . 7 71 5.2.3. DNS Name Retrieval . . . . . . . . . . . . . . . . . 9 72 6. Location-Aware DNS Name Configuration . . . . . . . . . . . . 9 73 7. Macro-Location-Aware DNS Name . . . . . . . . . . . . . . . . 10 74 8. Micro-Location-Aware DNS Name . . . . . . . . . . . . . . . . 11 75 9. DNS Name Management for Mobile IoT Devices . . . . . . . . . 11 76 10. Service Discovery for IoT Devices . . . . . . . . . . . . . . 11 77 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 78 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 79 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 80 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 14.1. Normative References . . . . . . . . . . . . . . . . . . 13 82 14.2. Informative References . . . . . . . . . . . . . . . . . 13 83 Appendix A. Changes from draft-jeong-ipwave-iot-dns-autoconf-03 16 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 86 1. Introduction 88 Many Internet of Things (IoT) devices (e.g., sensors, actuators, and 89 in-vehicle units) have begun to have wireless communication 90 capability (e.g., WiFi, Bluetooth, and ZigBee) for monitoring and 91 remote-controlling in a local network or the Internet. According to 92 the capacity, such IoT devices can be categorized into high-capacity 93 devices and low-capacity devices. High-capacity devices have a high- 94 power processor and a large storage, such as vehicles, road 95 infrastructure devices (e.g., road-side unit, traffic light, and 96 loop-detector), appliances (e.g., television, refrigerator, air 97 conditioner, and washing machine), and smart devices (smartphone and 98 tablet). They are placed in environments (e.g., vehicle, road 99 network, home, office, shopping mall, and smart grid) for the direct 100 use for human users, and they require the interaction with human 101 users. Low-capacity devices have a low-power processor and a small 102 storage, such as sensors (e.g., in-vehicle units, light sensor, 103 meter, and fire detector) and actuators (e.g., vehicle engine, signal 104 light, street light, and room temperature controller). They are 105 installed for the easy management of environments (e.g., vehicle, 106 road network, home, office, store, and factory), and they do not 107 require the interaction with human users. 109 For the Internet connectivity of IoT devices, a variety of parameters 110 (e.g., address prefixes, default routers, and DNS servers) can be 111 automatically configured by Neighbor Discovery (ND) for IP Version 6, 112 IPv6 Stateless Address Autoconfiguration, and IPv6 Router 113 Advertisement (RA) Options for DNS Configuration [RFC4861][RFC4862] 114 [RFC8106]. 116 For these IoT devices, the manual configuration of DNS names will be 117 cumbersome and time-consuming as the number of them increases rapidly 118 in a network. It will be good for such DNS names to be automatically 119 configured such that they are readable to human users. 121 Multicast DNS (mDNS) in [RFC6762] can provide DNS service for 122 networked devices on a local link (e.g., home network and office 123 network) without any conventional recursive DNS server. mDNS also 124 supports the autoconfiguration of a device's DNS name without the 125 intervention of the user. mDNS aims at the DNS naming service for 126 the local DNS names of the networked devices on the local link rather 127 than the DNS naming service for the global DNS names of such devices 128 in the Internet. However, for IoT devices accessible from the 129 Internet, mDNS cannot be used. Thus, a new autoconfiguration scheme 130 becomes required for the global DNS names of IoT devices. 132 This document proposes an autoconfiguration scheme for the global (or 133 local) DNS names of IoT devices. Since an autoconfigured DNS name 134 contains the model identifier (ID) of a device, IoT users in the 135 Internet (or local network) can easily identify such a device. The 136 autoconfigured DNS names and corresponding IP addresses of the IoT 137 devices are registered into local or remote authoritative DNS servers 138 that manage the DNS suffixes of the DNS domain names. With these DNS 139 names, they will be able to monitor and remote-control their IoT 140 devices with their smart devices (e.g., smartphone and tablet PC) by 141 resolving their DNS names into the corresponding IP addresses. 143 For cloud-based DNS naming services of IoT devices, a cloud server 144 can collect DNS zone files having the global DNS names and IP 145 addresses of the IoT devices from multiple DNS servers and provide 146 IoT users with such global DNS names of IoT devices relevant to the 147 IoT users. These IoT users can monitor and remote-control their IoT 148 devices in the Internet with the global DNS names and IP addresses, 149 using their smart devices. 151 1.1. Applicability Statements 153 It is assumed that IoT devices have networking capability through 154 wired or wireless communication media, such as Ethernet [IEEE-802.3], 155 WiFi [IEEE-802.11][IEEE-802.11a][IEEE-802.11b][IEEE-802.11g] 156 [IEEE-802.11n], Dedicated Short-Range Communications (DSRC) 157 [DSRC-WAVE][IEEE-802.11p], Bluetooth [IEEE-802.15.1], and ZigBee 158 [IEEE-802.15.4] in a local area network (LAN) or personal area 159 network (PAN). Note that IEEE 802.11p was renamed IEEE 802.11 160 Outside the Context of a Basic Service Set (OCB) [IEEE-802.11-OCB] in 161 2012. 163 Also, it is assumed that each IoT device has a factory configuration 164 (called device configuration) having device model information by 165 manufacturer ID and model ID (e.g., vehicle, road-side unit, smart 166 TV, smartphone, tablet, and refrigerator). This device configuration 167 can be read by the device for DNS name autoconfiguration. 169 2. Requirements Language 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 173 document are to be interpreted as described in RFC 2119 [RFC2119]. 175 3. Terminology 177 This document uses the terminology described in [RFC4861] and 178 [RFC4862]. In addition, four new terms are defined below: 180 o Device Configuration: A factory configuration that has device 181 model information by manufacturer ID and model ID (e.g., vehicle, 182 road-side unit, smart TV, smartphone, tablet, and refrigerator). 184 o DNS Search List (DNSSL): The list of DNS suffix domain names used 185 by IPv6 hosts when they perform DNS query searches for short, 186 unqualified domain names [RFC8106]. 188 o DNSSL Option: IPv6 RA option to deliver the DNSSL information to 189 IPv6 hosts [RFC8106]. 191 4. Overview 193 This document specifies an autoconfiguration scheme for an IoT device 194 using device configuration and DNS search list. Device configuration 195 has device model information (e.g., device's manufacturer and model). 196 DNS search list has DNS suffix domain names that represent the DNS 197 domains of a network having the IoT device [RFC8106]. 199 As an IPv6 host, the IoT device can obtain DNS search list through 200 IPv6 Router Advertisement (RA) with DNS Search List (DNSSL) Option 201 [RFC4861][RFC8106] or DHCPv6 with Domain Search List Option 202 [RFC3315][RFC3736][RFC3646]. 204 The IoT device can construct its DNS name with the concatenation of 205 manufacturer ID, model ID, and domain name. Since there exist more 206 than one device with the same model, the DNS name should have a 207 unique identification (e.g., unique ID or serial ID) to differentiate 208 multiple devices with the same model. 210 Since both RA and DHCPv6 can be simultaneously used for the parameter 211 configuration for IPv6 hosts, this document considers the DNS name 212 autoconfiguration in the coexistence of RA and DHCP. 214 5. DNS Name Autoconfiguration 216 The DNS name autoconfiguration for an IoT device needs the 217 acquisition of DNS search list through either RA [RFC8106] or DHCPv6 218 [RFC3646]. Once the DNS search list is obtained, the IoT device 219 autonomously constructs its DNS name(s) with the DNS search list and 220 its device information. 222 5.1. DNS Name Format with Object Identifier 224 A DNS name for an IoT device can have the following format with 225 object identifier (OID), which is defined in [oneM2M-OID], as in 226 Figure 1: 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | unique_id.object_identifier.OID.domain_name | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 Figure 1: IoT Device DNS Name Format with OID 234 Fields: 236 unique_id unique identifier to guarantee the uniqueness 237 of the DNS name in ASCII characters. The 238 identifier MAY be alphanumeric with readability, 239 e.g., product name plus a sequence number. 241 object_identifier device's object identifier that consists of a 242 higher arc, that is, M2M node indication ID ( 243 i.e., the concatenation of the managing 244 organization, administration, data country 245 code, and M2M node) and a sequence of four 246 arcs (i.e., manufacturer ID, model ID, serial 247 ID, and expanded ID) as defined in 248 [oneM2M-OID]. The fields are seperated by an 249 underscore '_'. 251 OID subdomain for the keyword of OID to indicate 252 that object_identifier is used. 254 domain_name domain name that represents a DNS domain for 255 the network having the IoT devices. 257 Note each subdomain (i.e., unique_id, object_identifier, OID, and 258 domain_name) in the domain name format in Figure 1 is expressed using 259 the name syntax described in [RFC1035]. 261 5.2. Procedure of DNS Name Autoconfiguration 263 The procedure of DNS name autoconfiguration is performed through a 264 DNSSL option delivered by either RA [RFC8106] or DHCPv6 [RFC3646]. 266 5.2.1. DNS Name Generation 268 When as an IPv6 host a device receives a DNSSL option through either 269 RA or DHCPv6, it checks the validity of the DNSSL option. If the 270 option is valid, the IPv6 host performs the DNS name 271 autoconfiguration with each DNS suffix domain name in the DNSSL 272 option as follows: 274 1. The host constructs its DNS name with the DNS suffix domain name 275 along with device configuration (i.e., manufacturer ID, model ID, 276 and serial ID) and a selected identifier (as unique_id) that is 277 considered unique, which is human-friendly, as shown in Figure 1. 279 2. The host constructs an IPv6 unicast address as a tentative 280 address with a 64-bit network prefix and the last 64 bits of the 281 MD5 hashed value of the above DNS name. 283 3. The host constructs the solicited-node multicast address in 284 [RFC4861] corresponding to the tentative IPv6 address. 286 4. The host performs Duplicate Address Detection (DAD) for the IPv6 287 address with the solicited-node multicast address [RFC4861] 288 [RFC4862]. 290 5. If there is no response from the DAD, the host sets the IPv6 291 tentative address as its IPv6 unicast address and regards the 292 constructed DNS name as unique on the local link. Otherwise, 293 since the DAD fails because of DNS name conflict, go to Step 1 294 for a new DNS name generation with another identifier for 295 unique_id. 297 6. Since the DNS name is proven to be unique, it is used as the 298 device's DNS name and the DNS autoconfiguration is done for the 299 given DNS suffix domain name. Also, the host joins the 300 solicited-node multicast address for the verified DNS name in 301 order to prevent other hosts from using this DNS name. 303 When the DNS search list has more than one DNS suffix domain name, 304 the IPv6 host repeats the above procedure until all of the DNS 305 suffixes are used for the DNS name autoconfiguration along with the 306 IPv6 unicast autoconfiguration corresponding to the DNS name. 308 5.2.2. DNS Name Collection 310 Once as IPv6 hosts the devices have autoconfigured their DNS names, 311 as a collector, any IPv6 node (i.e., router or host) in the same 312 subnet can collect the device DNS names using IPv6 Node Information 313 (NI) protocol [RFC4620]. 315 For a collector to collect the device DNS names without any prior 316 node information, a new NI query needs to be defined. That is, a new 317 ICMPv6 Code (e.g., 3) SHOULD be defined for the collection of the 318 IPv6 host DNS names. The Data field is not included in the ICMPv6 319 header since the NI query is for all the IPv6 hosts in the same 320 subnet. The Qtype field for NI type is set to 2 for Node Name. 322 The query SHOULD be transmitted by the collector to a link-local 323 multicast address for this NI query. Assume that a link-local scope 324 multicast address (e.g., all-nodes multicast address, FF02::1) SHOULD 325 be defined for device DNS name collection such that all the IPv6 326 hosts join this link-local multicast address for the device DNS name 327 collection service. 329 When an IPv6 host receives this query sent by the collector in 330 multicast, it transmits its Reply with its DNS name with a random 331 interval between zero and Query Response Interval, as defined by 332 Multicast Listener Discovery Version 2 [RFC3810]. This randomly 333 delayed Reply allows the collector to collect the device DNS names 334 with less frame collision probability by spreading out the Reply time 335 instants. 337 After the collector collects the device DNS names, it resolves the 338 DNS names into the corresponding IPv6 addresses by NI protocol 339 [RFC4620] with the ICMPv6 Code 1 of NI Query. This code indicates 340 that the Data field of the NI Query has the DNS name of an IoT 341 device. The IoT device that receives this NI query sends the 342 collector an NI Reply with its IPv6 address in the Data field. 344 For DNS name resolution service, the collector can register the 345 pair(s) of DNS name and IPv6 address for each IPv6 host into an 346 appropriate designated DNS server for the DNS domain suffix of the 347 DNS name. It is assumed that the collector is configured to register 348 DNS names into the designated DNS server in a secure way based on 349 DNSSEC [RFC4033][RFC6840]. This registration of the DNS name and 350 IPv6 address can be performed by DNS dynamic update [RFC2136]. 351 Before registering the DNS name into the designated DNS server, the 352 collector SHOULD verify the uniqueness of the DNS name in the 353 intended DNS domain by sending a DNS query for the resolution of the 354 DNS name. If there is no corresponding IPv6 address for the queried 355 DNS name, the collector registers the DNS name and the corresponding 356 IPv6 address for each IPv6 host into the designated DNS server. On 357 the other hand, if there is such a corresponding IPv6 address, the 358 DNS name is regarded as duplicate (i.e., not unique), and so the 359 corresponder notifies the corresponding IoT device with the duplicate 360 DNS name of an error message of DNS name duplication using NI 361 protocol. When an IoT device receives such a DNS name duplication 362 error, it needs to construct a new DNS name and repeats the procedure 363 of device DNS name generation along with the uniqueness test of the 364 device DNS name in its subnet. 366 The two separate procedures of the DNS name collection and IPv6 367 address resolution in the above NI protocol can be consolidated into 368 a single collection for the pairs of DNS names and the corresponding 369 IPv6 addresses. For such an optimization, a new ICMPv6 Code (e.g., 370 4) is defined for the NI Query to query the pair of a DNS name and 371 the corresponding IPv6 address. With this code, the collector can 372 collect the pairs of each IoT device's DNS name and IPv6 address in 373 one NI query message rather than two NI query messages. 375 For DNS name collection for IoT devices as IPv6 hosts, DHCPv6 376 [RFC3315] can be used instead of the NI protocol. For this purpose, 377 a new DHCP option (called DNSNA option) needs to be defined to 378 collect the pair of a DNS name and the corresponding IPv6 address of 379 an IoT device. As a DNS information collector, a DHCPv6 server (or a 380 router running a DHCPv6 server) sends a request message for the DHCP 381 DNSNA option to IoT devices as its DHCPv6 clients under its address 382 pool. The clients respond to this request message by sending the 383 DHCPv6 server a reply message with their DNS information. Thus, the 384 DHCPv6 server can collect the pairs of DNS names and the 385 corresponding IPv6 addresses of the IoT devices. Then, as a 386 collector, the DHCPv6 server can register the DNS names and the 387 corresponding IPv6 addresses of IoT devices into the designated DNS 388 server. 390 5.2.3. DNS Name Retrieval 392 A smart device like smartphone can retrieve the DNS names of IoT 393 devices by contacting a global (or local) DNS server having the IoT 394 device DNS names. If the smart device can retrieve the zone file 395 with the DNS names, it can display the information of IoT devices in 396 a target network, such as home network and office network. With this 397 information, the user can monitor and control the IoT devices in the 398 Internet (or local network). To monitor or remote-control IoT 399 devices, Constrained Application Protocol (CoAP) can be used 400 [RFC7252]. 402 6. Location-Aware DNS Name Configuration 404 If the DNS name of an IoT device includes location information, it 405 allows users to easily identify the physical location of each device. 406 This document proposes the representation of a location in a DNS 407 name. In this document, the location in a DNS name consists of two 408 levels for a detailed location specification, such as macro-location 409 for a large area and micro-location for a small area. 411 To denote both macro-location (i.e., mac_loc) and micro-location 412 (i.e., mic_loc) into a DNS name, the following format is described as 413 in Figure 2: 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | unique_id.object_identifier.OID.mic_loc.mac_loc.LOC.domain_name | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 Figure 2: Location-Aware Device DNS Name Format 421 Fields: 423 unique_id unique identifier to guarantee the uniqueness 424 of the DNS name in ASCII characters. The 425 identifier MAY be alphanumeric with readability, 426 such as product name plus a sequence number. 428 object_identifier device's object identifier that consists of a 429 higher arc, that is, M2M node indication ID ( 430 i.e., the concatenation of the managing 431 organization, administration, data country 432 code, and M2M node) and a sequence of four 433 arcs (i.e., manufacturer ID, model ID, serial 434 ID, and expanded ID) as defined in 435 [oneM2M-OID]. The fields are seperated by an 436 underscore '_'. 438 OID subdomain for the keyword of OID to indicate 439 that object_identifier is used. 441 mic_loc device's micro-location, such as center, edge, 442 and corner. 444 mac_loc device's macro-location, such as road segment. 446 LOC subdomain for the keyword of LOC to indicate 447 that mac_loc and mic_loc are used. 449 domain_name domain name that represents a DNS domain for 450 the network having the IoT devices. 452 Note each subdomain (e.g., mic_loc and mac_loc) in the domain name 453 format in Figure 2 is expressed using the name syntax described in 454 [RFC1035]. 456 7. Macro-Location-Aware DNS Name 458 If location information (such as cross area, intersection, and road 459 segment in a road network) is available to an IoT device, a keyword, 460 coordinate, or location ID for the location information can be used 461 to construct a DNS name as subdomain name. This location information 462 lets users track the position of mobile devices (such as vehicle, 463 smartphone, and tablet). The physical location of the device is 464 defined as macro-location for DNS naming. 466 A subdomain name for macro-location (denoted as mac_loc) MAY be 467 placed between micro-location (denoted as mic_loc) and the keyword 468 LOC of the DNS name format in Figure 2. For the localization of 469 macro-location, a localization scheme for indoor or outdoor can be 470 used [SALA]. 472 8. Micro-Location-Aware DNS Name 474 An IoT device can be located in the center or edge in a place that is 475 specified by macro-location. For example, assume that a loop- 476 detector is located in the start or end position of a road segment. 477 If the DNS name for the loop-detector contains the start or end 478 position of the road segment, a road network administrator can find 479 it easily. In this document, for this DNS naming, the detailed 480 location for an IoT device can be specified as a micro-location 481 subdomain name. 483 A subdomain name for micro-location (denoted as mic_loc) MAY be 484 placed between the keyword OID and macro-location (denoted as 485 mac_loc) of the DNS name format in Figure 2. For the localization of 486 micro-location, a localization scheme for indoor or outdoor can be 487 used [SALA]. 489 9. DNS Name Management for Mobile IoT Devices 491 Some IoT devices can have mobility, such as vehicle, smartphone, 492 tablet, laptop computer, and cleaning robot. This mobility allows 493 the IoT devices to move from a subnet to another subnet where subnets 494 can have different domain suffixes, such as 495 coordinate.road_segment.road, coordinate.intersection.road, 496 living_room.home and garage.home. The DNS name change (or addition) 497 due to the mobility should be considered. 499 To deal with DNS name management in mobile environments, whenever an 500 IoT device enters a new subnet and receives DNS suffix domain names, 501 it generates its new DNS names and registers them into a designated 502 DNS server, specified by RDNSS option. 504 When the IoT device recognizes the movement to another subnet, it can 505 delete its previous DNS name(s) from the DNS server having the DNS 506 name(s), using DNS dynamic update [RFC2136]. For at least one DNS 507 name to remain in a DNS server for the location management in Mobile 508 IPv6 [RFC6275], the IoT device does not delete its default DNS name 509 in its home network in Mobile IPv6. 511 10. Service Discovery for IoT Devices 513 DNS SRV resource record (RR) can be used to support the service 514 discovery of the services provided by IoT devices [RFC2782]. This 515 SRV RR specifies a service name, a transport layer protocol, the 516 corresponding port number, and an IP address of a process running in 517 an IP host as a server to provide a service. An instance for a 518 service can be specified in this SRV RR in DNS-based service 519 discovery [RFC6763]. After the DNS name registration in Section 5.2, 520 IoT devices can register their services in the DNS server via a 521 router with DNS SRV RRs for their services. 523 After the service registration, an IoT user can retrieve services 524 available in his/her target network through service discovery, which 525 can fetch the SRV RRs from the DNS server in the target network. 526 Once (s)he retrieves the list of the SRV RRs, (s)he can monitor or 527 remote-control the devices or their services by using the known 528 protocols and domain information of the devices or their services. 529 For this monitoring or remote-controlling of IoT devices, Constrained 530 Application Protocol (CoAP) can be used [RFC7252]. 532 11. Security Considerations 534 This document shares all the security issues of the NI protocol that 535 are specified in the "Security Considerations" section of [RFC4620]. 537 To prevent the disclosure of location information for privacy 538 concern, the subdomains related to location can be encrypted by a 539 shared key or public-and-private keys. For example, a DNS name of 540 vehicle1.oid1.OID.coordinate1.road_segment_id1.LOC.road can be 541 represented as vehicle1.oid1.OID.xxx.yyy.LOC.road where vehicle1 is 542 unique ID, oid1 is object ID, xxx is a string of the encrypted 543 representation of the coordinate (denoted as coordinate1) in a road 544 segment, and yyy is a string of the encrypted representation of the 545 road segment ID (denoted as road_segment_id1). Thus, the location of 546 the vehicle1 can be protected from unwanted users by encryption. 548 12. Acknowledgments 550 This work was supported by Basic Science Research Program through the 551 National Research Foundation of Korea (NRF) funded by the Ministry of 552 Education (2017R1D1A1B03035885). 554 This work was supported in part by Global Research Laboratory Program 555 through the NRF funded by the Ministry of Science and ICT (MSIT) 556 (NRF-2013K1A1A2A02078326) and by the DGIST R&D Program of the MSIT 557 (18-EE-01). 559 13. Contributors 561 This document is the group work of IPWAVE working group. This 562 document has the following contributing authors considered co- 563 authors: 565 o Keuntae Lee (Sungkyunkwan University) 567 o Seokhwa Kim (Sungkyunkwan University) 569 14. References 571 14.1. Normative References 573 [RFC1035] Mockapetris, P., "Domain Names - Implementation and 574 Specification", RFC 1035, November 1987. 576 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 577 Requirement Levels", BCP 14, RFC 2119, March 1997. 579 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 580 C., and M. Carney, "Dynamic Host Configuration Protocol 581 for IPv6 (DHCPv6)", RFC 3315, July 2003. 583 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 584 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 585 December 2003. 587 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 588 (DHCP) Service for IPv6", RFC 3736, April 2004. 590 [RFC4033] Arends, R., Ed., Austein, R., Larson, M., Massey, D., and 591 S. Rose, "DNS Security Introduction and Requirements", 592 RFC 4033, March 2005. 594 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 595 "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, 596 September 2007. 598 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 599 Address Autoconfiguration", RFC 4862, September 2007. 601 [RFC6840] Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and 602 Implementation Notes for DNS Security (DNSSEC)", RFC 6840, 603 February 2013. 605 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 606 "IPv6 Router Advertisement Options for DNS Configuration", 607 RFC 8106, March 2017. 609 14.2. Informative References 611 [DSRC-WAVE] 612 Morgan, Y., "Notes on DSRC & WAVE Standards Suite: Its 613 Architecture, Design, and Characteristics", 614 IEEE Communications Surveys & Tutorials, 12(4), 2012. 616 [IEEE-802.11] 617 IEEE Std 802.11, "Part 11: Wireless LAN Medium Access 618 Control (MAC) and Physical Layer (PHY) Specifications", 619 March 2012. 621 [IEEE-802.11-OCB] 622 IEEE 802.11 Working Group, "Part 11: Wireless LAN Medium 623 Access Control (MAC) and Physical Layer (PHY) 624 Specifications", IEEE Std 802.11-2016, December 2016. 626 [IEEE-802.11a] 627 IEEE Std 802.11a, "Part 11: Wireless LAN Medium Access 628 Control (MAC) and Physical Layer (PHY) specifications - 629 High-speed Physical Layer in the 5 GHZ Band", September 630 1999. 632 [IEEE-802.11b] 633 IEEE Std 802.11b, "Part 11: Wireless LAN Medium Access 634 Control (MAC) and Physical Layer (PHY) specifications - 635 Higher-Speed Physical Layer Extension in the 2.4 GHz 636 Band", September 1999. 638 [IEEE-802.11g] 639 IEEE P802.11g/D8.2, "Part 11: Wireless LAN Medium Access 640 Control (MAC) and Physical Layer (PHY) specifications - 641 Further Higher Data Rate Extension in the 2.4 GHz Band", 642 April 2003. 644 [IEEE-802.11n] 645 IEEE P802.11n/D9.0, "Part 11: Wireless LAN Medium Access 646 Control (MAC) and Physical Layer (PHY) specifications - 647 Amendment 5: Enhancements for Higher Throughput", March 648 2009. 650 [IEEE-802.11p] 651 IEEE Std 802.11p, "Part 11: Wireless LAN Medium Access 652 Control (MAC) and Physical Layer (PHY) Specifications - 653 Amendment 6: Wireless Access in Vehicular Environments", 654 July 2010. 656 [IEEE-802.15.1] 657 IEEE Std 802.15.1, "Part 15.1: Wireless Medium Access 658 Control (MAC) and Physical Layer (PHY) specifications for 659 Wireless Personal Area Networks (WPANs)", June 2005. 661 [IEEE-802.15.4] 662 IEEE Std 802.15.4, "Part 15.4: Low-Rate Wireless Personal 663 Area Networks (LR-WPANs)", September 2011. 665 [IEEE-802.3] 666 IEEE Std 802.3, "IEEE Standard for Ethernet", December 667 2012. 669 [oneM2M-OID] 670 oneM2M, "Object Identifier based M2M Device Identification 671 Scheme", February 2014. 673 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 674 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 675 RFC 2136, April 1997. 677 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 678 specifying the location of services (DNS SRV)", RFC 2782, 679 February 2000. 681 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 682 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 684 [RFC4620] Crawford, M. and B. Haberman, Ed., "IPv6 Node Information 685 Queries", RFC 4620, August 2006. 687 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 688 Support in IPv6", RFC 6275, July 2011. 690 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 691 February 2013. 693 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 694 Discovery", RFC 6763, February 2013. 696 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 697 Application Protocol (CoAP)", RFC 7252, June 2014. 699 [SALA] Jeong, J., Yeon, S., Kim, T., Lee, H., Kim, S., and S. 700 Kim, "SALA: Smartphone-Assisted Localization Algorithm for 701 Positioning Indoor IoT Devices", Springer Wireless 702 Networks, Vol. 24, No. 1, January 2018. 704 Appendix A. Changes from draft-jeong-ipwave-iot-dns-autoconf-03 706 The following changes are made from draft-jeong-ipwave-iot-dns- 707 autoconf-03: 709 o In Informative References, the reference to IEEE 802.11-OCB is 710 updated. 712 Authors' Addresses 714 Jaehoon Paul Jeong 715 Department of Software 716 Sungkyunkwan University 717 2066 Seobu-Ro, Jangan-Gu 718 Suwon, Gyeonggi-Do 16419 719 Republic of Korea 721 Phone: +82 31 299 4957 722 Fax: +82 31 290 7996 723 EMail: pauljeong@skku.edu 724 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 726 Sejun Lee 727 Ericsson-LG 728 77, Heungan-Daero 81 Beon-Gil, Dongan-Gu 729 Anyang-Si, Gyeonggi-Do 14117 730 Republic of Korea 732 Phone: +82 31 450 4099 733 EMail: prosejun14@gmail.com 735 Jung-Soo Park 736 Electronics and Telecommunications Research Institute 737 218 Gajeong-Ro, Yuseong-Gu 738 Daejeon 34129 739 Republic of Korea 741 Phone: +82 42 860 6514 742 EMail: pjs@etri.re.kr